System Design Interview Cheat Sheet
A good cheat sheet does not win the interview for you — it stops you freezing. When the prompt lands and your mind goes blank, having the structure, the numbers and the components one glance away lets you start with a plan instead of a panic. This is that one page: the template to run any round, the figures to justify your decisions, the building blocks to reach for, the concepts stated in a line, and the patterns that match a workload to a design.
Use it as a reference to reason from, not a script to recite. Interviewers can tell instantly when a candidate is reading a memorised list versus actually choosing components for the problem in front of them. Learn what is below until it is familiar, then practise turning it into a defended design out loud — that second step is the one that passes the system design interview.
The answer template
Run every round in the same order so you cover what the interviewer is grading and never lose track of time.
| Phase | Time | What you do |
|---|---|---|
| Clarify | 3–5 min | Scope functional features (a small core) and non-functional needs (scale, latency, availability, consistency). |
| Estimate | ~5 min | Back-of-the-envelope DAU, QPS, storage, bandwidth — and use them to justify choices. |
| API | ~5 min | The key endpoints, request/response shapes, pagination. |
| High-level design | 5–10 min | Client → CDN → load balancer → API gateway → app servers → cache / database. Add pieces as needed. |
| Deep dive | ~15 min | 2–3 critical components: database choice, caching, sharding, one domain challenge. |
| Wrap up | ~5 min | Bottlenecks, trade-offs, monitoring, extensions. |
Numbers to know cold
You do not need exact figures — you need order-of-magnitude numbers to estimate scale and justify decisions on the spot.
Latency ladder (orders of magnitude): memory read ~100 ns · SSD read ~16 µs · datacenter round trip ~0.5 ms · disk seek ~1–10 ms · cross-continent round trip ~150 ms. The lesson: a cross-region hop is roughly a million times slower than a memory read, which is why you cache and colocate.
Storage, powers of two: 2^10 = 1 KB · 2^20 = 1 MB · 2^30 = 1 GB · 2^40 = 1 TB · 2^50 = 1 PB.
Estimation shortcuts:
| Quantity | Shortcut |
|---|---|
| QPS | DAU × actions per user per day ÷ 86,400 seconds; peak ≈ 2–3× average |
| Storage | items/day × bytes/item × retention days × replication factor |
| Availability | 99.9% ≈ 8.7 h/yr down · 99.99% ≈ 52 min/yr · 99.999% ≈ 5 min/yr |
The component cheat sheet
Every design is assembled from the same pieces. Know when to reach for each and what it costs you.
| Component | Use when | Watch out for |
|---|---|---|
| Load balancer | Spreading traffic across servers | Make it redundant; pick a routing algorithm |
| CDN | Global static content and media | Invalidation and cost |
| Cache | Hot reads dominate | Staleness; invalidation; cache-aside vs write-through |
| SQL | Transactions, joins, strong consistency | Harder to scale horizontally |
| NoSQL | Horizontal scale, flexible schema, high writes | Weaker joins and transactions |
| Message queue | Decouple services, buffer bursts, async work | Ordering; at-least-once vs exactly-once |
| Sharding | Data outgrows one node | Shard-key choice; hotspots; cross-shard queries |
| Replication | Read scale and availability | Replication lag; consistency on failover |
Core concepts in one line
These are the system design basics the follow-ups probe. Each has a full deep-dive on the Zynter blog if you want more.
- CAP theorem — under a network partition you choose consistency or availability, not both. Say which you are trading and why.
- Consistency models — strong, eventual, read-your-writes, monotonic. Match the model to the feature (a bank balance is not a like count).
- Caching strategies — cache-aside (lazy load), write-through (write both), write-back (write cache, flush later), read-through. Each trades freshness against latency.
- Consistent hashing — place keys on a ring so adding or removing a node moves about 1/N of the keys instead of all of them.
- Load-balancing algorithms — round-robin, weighted, least-connections, consistent-hash, IP-hash.
- Idempotency — attach a key to each request so retries don't double-charge; essential for payments.
Patterns: match the workload
Half of system design is recognising which pattern the workload wants, then reaching for the matching stack.
- Read-heavy (feeds, catalogues) → cache + CDN + read replicas; denormalise for fast reads.
- Write-heavy (logging, metrics, ingestion) → message queue to buffer bursts + sharding + LSM-tree stores; batch writes.
- Global, low-latency → CDN + geo-sharding + edge; accept eventual consistency where the feature tolerates it.
- Strong-consistency (payments, inventory) → single leader + transactions + idempotency keys; correctness over raw throughput.
System design
HLD · Design a URL shortener · 45 min
Turn the cheat sheet into a defended design, out loud
How to use the cheat sheet (not recite it)
The trap is treating this as a list to read back. The numbers exist to justify a choice — "at roughly fifty thousand QPS with a 100-to-1 read ratio, I'll put a cache in front of read replicas." The components are options, not an answer — naming Kafka proves nothing; explaining why a queue decouples your write path does. And the concepts only count when you apply the trade-off to this problem: "I'll take eventual consistency on the feed because a few seconds of staleness is fine, but strong consistency on the payment because double-charging is not."
That application — picking from the sheet and defending the pick under pushback — is exactly what the round grades on its four dimensions: problem solving, communication, technical execution and time management. The cheat sheet gets you to the start line; saying it out loud against follow-ups gets you across.
System design
HLD · Design a news feed · 45 min
Defend a cache and sharding choice while an interviewer pushes back
Frequently asked questions
What should a system design answer template look like?
Run a fixed sequence: clarify functional and non-functional requirements, estimate scale, design the API, draw the high-level architecture, deep dive into two or three components, then wrap up on bottlenecks and trade-offs — roughly five, five, five, ten, fifteen and five minutes in a forty-five-minute round. The template matters less for its exact steps than for the discipline it enforces: always clarify before you draw, and protect enough time for the deep dive, where the strongest signal is. It keeps you structured and stops the most common time-management failures.
What numbers do I need to memorise for system design?
Order-of-magnitude figures, not precise ones. Know the latency ladder (memory in nanoseconds, a datacenter round trip around half a millisecond, a cross-continent round trip around 150 milliseconds), the powers of two for storage (a gigabyte is 2^30 bytes), and simple estimation shortcuts: QPS is roughly daily active users times actions per day divided by 86,400, with peak two to three times average. These let you size a system live and justify why you need a cache, a shard or a queue.
When do I use SQL vs NoSQL in a system design interview?
Reach for SQL when you need transactions, joins and strong consistency over structured data — payments, orders, anything where correctness is non-negotiable. Reach for NoSQL when you need horizontal scale, a flexible schema or very high write throughput, and can tolerate weaker joins and looser consistency — feeds, logs, session stores, large catalogues. The interview answer is never just the name; it is tying the choice to the requirement: "this is write-heavy and schema-flexible, so I'd use a wide-column store and shard by user."
What is the CAP theorem in simple terms?
CAP says that when a network partition happens — some nodes cannot talk to others — a distributed system must choose between consistency (every read sees the latest write) and availability (every request still gets a response). You cannot have both during the partition. In practice you design CP systems (reject requests to stay consistent, like a payment ledger) or AP systems (stay available and reconcile later, like a social feed). Naming which you are trading, and why it fits the feature, is what the interviewer wants.
How do I pick between caching strategies?
Match the strategy to the read/write pattern. Cache-aside (the application loads the cache on a miss) is the default for read-heavy workloads and is simple to reason about. Write-through (write to cache and store together) keeps the cache fresh at the cost of write latency, good when reads must never be stale. Write-back (write to cache, flush to the store later) is fastest for writes but risks loss on failure. Whichever you choose, mention the invalidation and the time-to-live, because stale cache data is a classic follow-up.
How do I practise using this cheat sheet out loud?
A cheat sheet lives in your head; the interview makes you deploy it in conversation. On Zynter, the system design track runs voice mock interviews modelled on real company loops — you sketch the architecture on a shared canvas, justify each component to a voice interviewer that asks "why that cache strategy?" and "what breaks at peak QPS?", and get a debrief on problem solving, communication, technical execution and time management. It is a genuine system design mock interview on demand, and the score is a practice signal, not a hiring decision.
Practise it on Zynter
The cheat sheet gets you to the start line. The offer is won defending your choices out loud.
Pick a high-level design scenario, sketch it on a shared canvas, and justify every component — cache strategy, shard key, consistency model — to a voice interviewer that keeps pushing, then read the debrief. Zynter.ai is on-demand mock interviews modelled on real company loops, with 150+ rounds across 20 companies (Sep 2026), including high-level design scenarios from URL shorteners to ride-sharing — about $8–$12 for a full 60-minute mock, and two free credits to start.
Practise a system design round →
Browse all interview tracks
Top comments (0)