scaling-evolutionlisted

# Scaling Evolution Grow a design one bottleneck at a time. A system that serves 1k users and one that serves 10M users are different architectures, but you do not jump between them — you walk a path where each step removes the *current* ceiling and exposes the next. Getting this wrong means either over-building day one (paying multi- region complexity for 1k users) or freezing when load doubles because the design was a memorized end-state, not a sequence of justified moves (GUIDE #7). ## When to reach for this A load increase is on the table ("what if traffic 10×?", "scale to millions"), the user asks where the bottleneck is or what breaks first, or a single-box design has outgrown one machine. Reach here to sequence the next two or three moves — never the whole roadmap at once. ## When NOT to Do not pre-build steps the numbers do not yet demand (YAGNI). Sharding, multi-region, and a message queue are *late* moves; proposing them for a system that fits on two boxes is the over-indexing this skill defends against. If the current load fits comfortably on a vertically-scaled box with a replica, stop — that is the cheapest design that meets the constraint, and it wins. Naming the next five tiers when only one is needed is a red flag, not foresight. ## Clarify first The path is driven entirely by numbers and constraints, so pin these down before moving (most come from `requirements-scoping` and `back-of-the-envelope`): - **Current and target scale** — today's QPS/data and the