I used to think system design started with boxes: load balancer, cache, message queue, database. It makes more sense to start with behavior.
What request is coming in? What state changes? Who needs the result? What can fail? Which part gets slow first?
Start with one machine
A single service and database are often enough to explain the product. From there, each new component should solve a concrete problem: caching for repeated reads, a queue for asynchronous work, replicas for read pressure, object storage for large files, and so on.
Separate state from compute
Stateless application servers are easier to scale horizontally because user state can live in databases, caches or other shared stores. The important skill is knowing where state belongs before adding more servers.
Ask the boring questions
What happens if the request is repeated? What if two users update the same record? What if the downstream service is unavailable? Those questions often reveal the real design work faster than drawing more components.
Related case studies