The System Design Interview Cheat Sheet That Actually Works

The system design interview is the one that separates offers by level. Two engineers can write identical code, but the one who can reason about a system serving ten million users the way they reason about a single function is the one who gets the senior title and the senior compensation.

The good news: it's the most learnable interview, because strong answers follow a structure. Interviewers aren't looking for the "right" architecture — they're looking for a clear framework, sound tradeoffs, and the judgement to go deep where it matters. This cheat sheet gives you that framework.

The 7-step framework (memorise this order)

Whatever the prompt — "design Twitter," "design a URL shortener," "design a rate limiter" — run these steps in order. The order *is* the signal.

1. 1Clarify requirements. Functional (what it does) and non-functional (scale, latency, availability, consistency). Never start drawing until you've scoped this.
2. 2Back-of-the-envelope estimates. Users, requests/sec, reads-vs-writes ratio, storage per year. These numbers justify every later decision.
3. 3Define the API. A handful of endpoints. This forces concrete thinking and frames the data flow.
4. 4Data model. Core entities and how they relate. Decide SQL vs NoSQL *here*, and say why.
5. 5High-level design. The boxes-and-arrows diagram: clients, load balancer, services, cache, database, queue. Keep it clean.
6. 6Deep dive. Pick the 1–2 hardest parts and go deep — the interviewer will steer you, or you choose the bottleneck.
7. 7Bottlenecks & tradeoffs. Name the single points of failure, hot spots, and what you'd do next. Ending on tradeoffs is a senior signal.

Back-of-the-envelope math you should have ready

You don't need precision — you need the right order of magnitude, fast. Keep these anchors memorised:

• 1 million requests/day ≈ 12 requests/sec (86,400 seconds in a day). Handy for converting DAU to QPS.
• Reads usually dominate writes by 10:1 or 100:1 for social/content systems — this drives your caching strategy.
• Assume peak ≈ 2–3× average traffic when sizing capacity.
• A row of a few hundred bytes × billions of rows quickly tells you whether you need sharding.

The scaling building blocks

Deep dives almost always draw on the same toolbox. Know each one, and — more importantly — know when *not* to use it.

Caching

The highest-leverage move in most designs. Put a cache (Redis, Memcached) in front of hot reads. Discuss cache invalidation (write-through vs write-back vs TTL) and the thundering-herd problem — that nuance is what interviewers probe for.

Load balancing

Distributes traffic across service instances. Mention health checks, and the difference between L4 (transport) and L7 (application) balancing. Sticky sessions if you must, statelessness if you can.

Database scaling: replication and sharding

Replication (primary + read replicas) scales reads and adds redundancy. Sharding (partitioning by a key) scales writes and storage — but introduces cross-shard queries and rebalancing pain. Always name the tradeoff you're accepting when you shard.

Asynchronous processing with queues

When work is slow or spiky, decouple it. A message queue (Kafka, RabbitMQ, SQS) lets you absorb bursts, retry failures, and keep the request path fast. Great answer for anything involving notifications, feeds, uploads, or analytics.

CDN and content delivery

Push static assets and cacheable content to the edge, close to users. One line in the interview, big latency win in reality.

The CAP theorem answer that sounds senior

Don't recite CAP as trivia. Apply it: "Payments must be consistent, so I'll accept lower availability there. The activity feed can be eventually consistent, so I'll favour availability and let replicas lag by a second." Feature-by-feature reasoning is exactly the judgement interviewers reward.

A worked mini-example: design a URL shortener

Run the framework fast:

• Requirements: shorten a URL, redirect, optional analytics. ~100M new URLs/month, read-heavy (redirects ≫ creations).
• Estimates: 100M/month ≈ 40 writes/sec; reads maybe 100× that → caching is essential.
• API: POST /shorten and GET /{code}.
• Data model: code → long_url, plus created_at. Billions of rows over time → plan for sharding by code.
• Key generation: base-62 encode an incrementing ID, or hash + collision check. Discuss the tradeoff.
• Design: client → LB → service → cache (hot codes) → DB. Redirects hit cache first.
• Tradeoffs: custom aliases vs collisions, analytics write amplification, cache invalidation on deletion.

Notice you never needed to memorise "the" URL-shortener architecture. You *derived* it from the framework. That's the entire skill.

Practising system design (where it gets hard)

System design is brutal to self-study because there's no autograder and few people to mock with. This is where AI-assisted prep shines: ask an AI to pose a design prompt, then talk through all seven steps while it plays a skeptical staff engineer poking at your bottlenecks. In a live interview, a real-time copilot such as OctoHires can surface a structured design — components, scale estimates, and tradeoffs — as scaffolding you reason on top of, not a script you read. You still make the calls; it just keeps the blank page from winning.

Memorise the seven steps, internalise the building blocks, and practise reasoning about tradeoffs out loud. Do that and the system design interview stops being the scary one — it becomes the round where you get to show exactly how you think.