01
Start with the problem before the architecture
System design interviews reward visible reasoning. Before naming services or databases, confirm the users, the core workflow, the scale that matters, and the constraints that change the design.
A short clarification phase prevents you from solving the wrong problem and gives the interviewer a way to guide the conversation.
02
Build the design in layers
Begin with a simple end-to-end path: client, entry point, application logic, data store, and the most important asynchronous work. Once that path is clear, deepen the areas that carry the biggest risk.
- Name the API or user action that starts the workflow.
- Explain data ownership and the read or write pattern.
- Introduce queues, caching, partitioning, or replicas only when a stated constraint requires them.
03
Close with tradeoffs and next checks
There is rarely one universally correct design. State what your approach optimises for, what it makes harder, and what you would measure after launch. This turns a diagram into an engineering decision.
If time remains, revisit the weakest point in the system: failure handling, data consistency, cost, privacy, or operational visibility.
QUICK RECAP
Key takeaways
- Clarify the user flow and constraints before drawing components.
- Add complexity only when it addresses a stated risk.
- Make tradeoffs explicit and name the signals you would monitor.