The first time I walked through a system design question in an interview, I spent 8 of my 45 minutes talking about load balancers before anyone had agreed on what the system was supposed to do. The interviewer was polite about it. I did not get the offer.
The core problem with system design interviews is that they’re open-ended in a way that invites rambling. There’s no green checkmark when you’re done. There’s no right answer. The structure has to come from you, and if you don’t have a process going in, you’ll improvise badly under pressure.
Here’s the framework I’ve found works consistently. It’s not the only one, and I’d be skeptical of anyone who claims theirs is the only one that works.
Before anything else: requirements (5 minutes, strictly)
Don’t start drawing boxes. Ask questions first.
Functional requirements are the “what”: what does the system need to do? For a URL shortener, it’s: create short URLs, redirect to originals, maybe track click counts. That’s it. Keep this list short. If you can’t fit it on a Post-it, you’ve overspecified.
Non-functional requirements are where most candidates underinvest. Ask:
- How many users? Daily active, not registered. (A system for 1M DAU vs 100M DAU is a completely different design.)
- What’s the read/write ratio?
- Is availability more important than consistency, or vice versa?
- What does “latency” mean here (p50? p99?)? Are we talking about 200ms or 20ms?
Interviewers at Google, Meta, and Stripe all cite the failure to ask non-functional questions as the most common early mistake they see. Asking them signals that you’ve thought about this before.
Back-of-envelope estimation (5 minutes)
This is not optional. Estimations ground the design in reality and help you make the right choices later.
The math you need: if you have 100M DAU and each user performs 10 actions per day, that’s 1 billion events per day, which is roughly 11,500 requests per second at steady state. (100M × 10 / 86,400 seconds ≈ 11,574 QPS.) Round to 12,000 QPS. That number will tell you whether a single database can handle reads, whether you need caching, and how big your write throughput challenge is.
For storage: 1M users × 1KB per record = 1GB, trivial. 1B rows × 1KB = 1TB, not trivial. 100B rows × 10KB = 1PB, very different problem. Do the multiplication out loud so the interviewer follows your reasoning.
I use powers of 10 and round aggressively. 86,400 seconds in a day becomes 100,000. A million is 10^6. This isn’t about precision; it’s about order of magnitude.
High-level design (10 minutes)
Now draw the boxes. At this stage you want: clients, an API gateway or load balancer, one or two application servers, a primary data store, and maybe a cache. That’s your skeleton.
For the URL shortener example:
- Client makes a POST to /shorten with the original URL
- Application server generates a 7-character ID (base62 gives you 3.5 trillion possibilities, more than enough)
- Stores the mapping in a relational DB (PostgreSQL works fine at this scale)
- GET /:id hits the app server, checks Redis cache first, falls back to DB, issues a 302 redirect
That’s a valid high-level design. Don’t add complexity until the interviewer asks for it or you’ve identified a specific bottleneck in your estimation math.
Deep dive: pick one interesting problem (15 minutes)
This is the part that separates candidates who’ve practiced from candidates who’ve read about system design. You need to pick the hardest sub-problem in your design and go deep on it. Don’t try to go deep on everything. Pick one.
Common areas worth a deep dive:
Database choice and schema design. SQL vs NoSQL is not a religious question. If you have structured data with clear relationships and you need transactions, SQL. If you have variable schema, need horizontal write scaling past what a single Postgres instance can handle, or are storing document-shaped data, NoSQL. Name a specific system (DynamoDB, Cassandra, MongoDB) and explain why, not just “I’d use a NoSQL database.”
Caching strategy. Redis for hot reads is usually right, but explain the eviction policy (LRU if recency matters, LFU if frequency matters), the TTL, and your cache invalidation approach. Cache invalidation is famously hard. If you wave it away, the interviewer notices.
Handling failures gracefully. What happens when a downstream service times out? Do you retry? With exponential backoff and jitter, hopefully. At what point do you circuit-break? For writes, does your system guarantee at-least-once or exactly-once delivery? These questions have concrete answers that good candidates give.
The Stack Overflow Developer Survey 2024 found that Redis and PostgreSQL are by far the most commonly used cache and database tools in production systems. Knowing them well means you can speak from real experience rather than hypotheticals, which comes through in interviews.
Wrap-up and tradeoffs (5 minutes)
End by acknowledging what you didn’t cover and what you’d change with more time. This is not a sign of weakness. Interviewers know you can’t design a full production system in 45 minutes. What they’re looking for is whether you know what you simplified and can articulate the cost of that simplification.
Something like: “I punted on the analytics write path. At 12,000 QPS of click events, I’d probably want a Kafka queue feeding a separate analytics service rather than writing directly to the main DB. That’s the first thing I’d add.” That sentence signals more engineering maturity than spending five extra minutes on your load balancer setup.
One note on practice
Reading about system design is not the same as doing it out loud. The specific skill the interview tests is verbal reasoning under ambiguity: you have to talk through a design in real time while keeping track of your own constraints, the interviewer’s reactions, and the clock.
The only way to get good at that is to practice it the way it will happen: out loud, timed, with a real question you haven’t seen before. Tools like Craqly support mock system design sessions where you can get real-time feedback on your structure and reasoning. The System Design Primer on GitHub (70,000+ stars) is still one of the best free resources for building foundational knowledge.
Frankly, if you can do three timed, out-loud practice sessions on different question types before your first real interview, you will be noticeably more coherent than candidates who only studied. That gap is larger than it sounds.