A Practical Roadmap for the System Design Interview

System design rounds are not knowledge tests. They are conversations about trade-offs under time pressure. The candidates who do well aren't the ones who memorized a sharded-Cassandra diagram — they are the ones who can scope a fuzzy problem, defend their choices, and revise calmly when the interviewer pushes back.

The four phases of a 45-minute round

1. Scoping (5–8 min): clarify users, functional requirements, non-functional requirements, and the one or two metrics that matter.
2. High-level design (10–15 min): name the major components, draw the request flow, and call out the API surface.
3. Deep dives (15–20 min): pick the riskiest two areas — usually data model, hot path, or consistency — and go deep.
4. Wrap (3–5 min): summarize what you'd build first, what you'd defer, and what you'd watch in production.

Scope before you draw

Almost every prompt — 'design Twitter', 'design a ride-share dispatcher', 'design a code review tool' — is intentionally underspecified. Resist the urge to start drawing. Instead, ask three concrete questions: who is the user, what is the one workflow we're optimizing, and what scale are we talking about? The answers narrow your design space by an order of magnitude.

Estimate, don't guess

Back-of-the-envelope math is how you justify your storage choice, your cache, your fan-out strategy. You don't need exact numbers — you need defensible orders of magnitude. Practice converting daily active users into queries per second, into bytes per day, into shards.

• 1 million DAU at 10 actions/day ≈ 116 writes/sec average, ~1k peak.
• 1 KB per event over 30 days ≈ 30 GB — fits on a single node, no sharding needed yet.
• Read:write ratios drive cache shape more than total volume.

Default to boring technology

Reach for Postgres, Redis, and a queue before you reach for Cassandra, Kafka, and Spark. Boring tools have known failure modes, and 'I'd start with Postgres and shard if writes exceed X' is a stronger answer than 'I'd use a globally distributed CRDT-backed store.' Save the exotic choices for problems that genuinely need them.

Talk about what breaks

Once your high-level design exists, narrate failure. What happens if the cache evicts? What if the database leader fails over mid-write? What if a downstream service returns 200 OK but the body is empty? The strongest signal you can send in a system design round is that you've operated systems, not just designed them.