A step-by-step system design interview framework
System design interviews are open-ended by design. You are usually being evaluated on how you clarify an ambiguous problem, choose a reasonable architecture, explain trade-offs, and adapt when a constraint changes. A simple sequence keeps the discussion collaborative instead of turning it into a list of technologies.
1. Clarify the problem and scope
Ask who uses the system and what the essential user journeys are. Separate must-have functions from optional ones. Confirm assumptions such as read versus write patterns, consistency needs, latency expectations, geographic scope, and what is explicitly out of scope.
2. Estimate scale only where it helps
Use supplied numbers when available. Otherwise state simple assumptions for users, requests, and stored data, then estimate rough orders of magnitude. Use the estimates to motivate a design decision; avoid spending the interview on false precision.
3. Define the interface and core data
Sketch the main API operations and the entities they read or change. Identify ownership, access patterns, and the queries the system must support. This reveals whether a relational model, key-value access, search index, or a combination is appropriate for the stated needs.
4. Draw a simple end-to-end design
Start with clients, an application layer, persistent storage, and any required external services. Walk through one important request from entry to response. Add a cache, queue, worker, index, or replica only when a requirement or bottleneck justifies it.
5. Follow the data and failure paths
Explain how data is written, read, updated, and recovered. Discuss what happens during a timeout, duplicate request, worker retry, or dependency failure. Mention observability and operational recovery when they matter to the design.
6. Find the bottleneck and evolve the design
Use the workload assumptions to identify likely pressure points. Then describe a targeted response, such as caching a hot read, partitioning a large dataset, moving slow work to a queue, or replicating read traffic. State what trade-off the change introduces.
Make trade-offs explicit
There is rarely one universally correct architecture. A cache can reduce repeated reads but introduces invalidation and staleness questions. Asynchronous processing can lower request latency but creates eventual consistency and retry concerns. Replicas can help read scale but add replication lag. Tie each choice to a stated requirement, and say what you would revisit if that requirement changed.
End with a concise recap
Summarize the main request flow, the decisions that matter most, the likely bottleneck, and one next improvement. If there was not enough time to explore a topic, name it as an open question instead of implying it has been solved.
For coding practice, see the coding interview preparation plan. For stories about your own work, use the STAR answer framework.