A system design interview is a conversation about decisions under uncertainty. The diagram matters because it makes assumptions and trade-offs visible.
- Clarify functional and non-functional requirements first.
- Estimate only what changes the design.
- Discuss failure, operations and evolution—not just the happy path.
Frame the problem
Identify users, core actions, consistency needs, latency targets, availability, geography, data sensitivity and expected growth. State which requirements you will prioritize in the first design.
Build the simplest credible path
Define APIs and data flow, then choose storage, compute and communication patterns. Explain why each component exists. Avoid adding queues, caches or microservices without a requirement that justifies them.
- Request path
- Data ownership
- Scaling boundary
- Failure behavior
- Observability and security
Evolve the design
Use bottlenecks to drive the next step. Discuss hot keys, retries, idempotency, backpressure, regional failure, migrations and cost. Tie choices to production experience where possible.
Common questions
Do I need exact capacity calculations?
Use defensible estimates that influence storage, throughput or architecture. State assumptions and keep the arithmetic simple.
What if I do not know a specific technology?
Describe the capability required and the trade-offs you would evaluate rather than bluffing product-specific knowledge.
Put the guide into practice
Turn good advice into a visible next action.
Cariew connects targeting, verified applications, preparation and interview improvement in one career workspace.
Start 7 days free