scalability-planninglisted

# Scalability planning Scalability is designed against a number, not a feeling. Start from a load model, find where it breaks, and design for the next order of magnitude: not ten, because that is today, and not a thousand, because that is architecture astronomy you will rebuild before you reach it. ## Method 1. **Build the load model first.** Requests per second at peak, data volume and growth rate, read/write ratio, payload sizes, and the concurrency shape (steady vs spiky): tied to the business driver (see capacity-planning, product-metrics). Every scaling decision references this model; designing for scale without a number is guessing which is why systems get over- and under-built at once. 2. **Find the bottleneck by math, then by test.** Trace the load through the system and compute where it saturates first (usually the database, a shared lock, or a single-threaded stage: see systems-profiling, concurrency-tuning); intuition picks the wrong component routinely. Confirm with load testing (see load-testing) and design the fix for the *real* bottleneck, not the scary-looking one. 3. **Scale horizontally by removing shared state.** Stateless services scale by adding instances (see autoscaling-policies); the hard part is the stateful tier. Push state to the data layer, make services share nothing, and design the data layer to scale (read replicas for read-heavy, sharding/partitioning for write-heavy: see sharding-p