backend-scaling-architecturelisted

# Backend scaling architecture Scale is not an architecture you install after launch. Keep the request path simple, measure its limiting resource, and choose the cheapest change that raises that limit before distributing state or data across more machines. Scope: this skill owns topology, workload placement, admission control, and capacity decisions. `backend-caching-and-performance` owns cache mechanics and hot-path tuning; `database-schema-and-migrations` owns schema, indexes, and query plans; `error-handling-and-resilience` owns retry/fallback mechanics; `api-design-rest-graphql` owns endpoint contracts; and `observability-logging-metrics-tracing` owns the evidence used to decide. ## 1. Measure the bottleneck before changing architecture - **Do not scale a hypothesis.** Name the saturated resource with evidence: CPU, memory, database connections, a lock, disk I/O, network, dependency quota, or queue lag. A request rate alone is not a bottleneck. - Establish the current and target workload, latency SLO, error budget, and headroom before proposing replicas, queues, or shards. “Handle 100k users” is incomplete without active concurrency, request mix, payload size, and peak-versus-average traffic. - Use `observability-logging-metrics-tracing` to correlate RED/USE signals with traces, and `backend-caching-and-performance` to profile the proven hot path. Re-run the same measurement after a change. - Apply the **one-big-instance-first rule**: if one larger insta