A system design is a set of choices made under constraints. Begin by defining what the system must do and how well it must do it. Without those requirements, a diagram can be detailed and still solve the wrong problem.
Turn usage into a workload
Clarify the main reads and writes, data size, retention, geographic distribution, peak traffic, and growth assumptions. Distinguish average load from bursts. Estimate orders of magnitude and label them as assumptions; the estimate should guide component choices, not pretend to be a precise forecast.
Draw the data path for one representative operation. Identify where state lives, which requests can be cached, which operations need ordering or atomicity, and which work can happen asynchronously. A cache is useful only when its freshness and invalidation rules fit the product. A queue absorbs bursts and separates timing, but introduces delivery, retry, and duplicate-processing concerns.
Treat failure as part of the normal design
For each dependency, ask what the caller sees when it is slow or unavailable. Add timeouts to bound waiting, retries only where operations are safe to repeat, and limits to prevent one failure from consuming all resources. Replication can improve availability or read capacity, but introduces consistency and recovery decisions. A load balancer spreads requests but cannot make an unhealthy application correct.
Make trade-offs explicit
Availability, consistency, latency, cost, and operational effort compete. There is no universal “scalable architecture”; the appropriate design depends on the workload and failure model. Start with the simplest design that meets known requirements, then identify a measured trigger for the next scaling step.
The AWS Well-Architected Framework organizes design review around operational excellence, security, reliability, performance, cost, and sustainability concerns.