System Design Interview Cheat Sheet: 15 Patterns to Know
596 words · Reviewed for accuracy
The fastest way to calm down in a system design interview is to realise it isn't a trivia test. Nobody expects you to recite the internals of every database ever shipped. What the interviewer wants is to watch you take a fuzzy prompt — "design Twitter," "design a parking lot" — and turn it into a structured conversation with a beginning, a middle, and defensible trade-offs. This page is the cheat sheet for that process.
The core idea: every system design answer follows the same spine — clarify requirements, estimate scale, sketch the API, design the data model, draw the high-level components, then drill into one or two bottlenecks. Memorise the spine, not a hundred architectures.
The six-step spine
- Clarify (3–5 min). Who uses it? Which features are in scope? Read-heavy or write-heavy? Any latency or consistency requirements? Skipping this step is the single most common way candidates sink themselves.
- Estimate (2–3 min). Back-of-envelope numbers: users, requests per second, storage per year. State them as assumptions out loud — the interviewer cares about the arithmetic, not the guesses.
- API sketch (2 min). Three or four endpoints. It forces you to be concrete before you start drawing boxes.
- Data model (5 min). Entities, relationships, and the SQL vs NoSQL call, justified by access patterns rather than fashion.
- High-level design (10 min). Clients, load balancer, app servers, database, cache, queue. One box per concern.
- Deep dive (remaining time). Let the interviewer pick the bottleneck, or pick the most interesting one yourself and say why.
The building blocks, one line each
| Block | Reach for it when… | Deeper read |
|---|---|---|
| Load balancer | more than one app server exists | load balancing techniques |
| Cache | reads dominate and data is reusable | caching strategies |
| Message queue | work can happen later, not inline | message queues |
| Sharding | one database can't hold the data or the writes | sharding strategies |
| Rate limiter | you must protect the service from abuse | rate limiting design |
One pattern to notice: the table is deliberately short. Interviewers would rather watch you reason deeply about three blocks you understand than gesture vaguely at ten you don't. Depth on a few primitives, applied to the specific numbers you estimated out loud, is what "strong senior" looks like from the other side of the table — not a diagram crowded with logos.
Trade-off phrases that earn points
Interviewers light up when you name a trade-off unprompted. Keep these in your pocket: "I'd take eventual consistency here because availability matters more for this read path." "A queue adds latency but buys us resilience." "Sharding solves capacity but makes cross-shard queries painful." You're showing judgment, not just vocabulary.
Common mistakes
- Diving into Kafka and Cassandra in the first two minutes. Start boring: a server and a database. Add complexity only when a requirement forces it.
- Never asking how big the system is. A design for 100 users and one for 100 million are different interviews.
- Designing in silence. Narrate your reasoning — the interviewer grades the thinking, not the final diagram.
- Forgetting the follow-through: monitoring, failure modes, "what breaks first at 10x?"
FAQ
How long should each phase take? In a 45-minute round: roughly 5 clarifying, 5 estimating and sketching, 20 on the high-level design, and 15 on deep dives. Flex to the interviewer's steering.
Do I need to know specific technologies? Know what a queue, a cache, and a document store do and when you'd pick each. Brand names are optional; reasoning is mandatory.
Ready to run the spine under pressure? Rehearse with Aissence mock interviews, then try a full walkthrough like designing a URL shortener.