The System Design Interview: A Senior Engineer's Framework

A system design interview is not a test of whether you have memorized how Instagram shards its database. It is a test of whether you can take a vague problem, make it concrete, and reason out loud about trade-offs while someone watches. I have been on both sides of the table for years, and the candidates who do well are almost never the ones who know the most trivia. They are the ones who have a repeatable way of moving through the problem so they never freeze.

This is that framework. It is the same one I use when I actually design services at work, minus the luxury of a week to think. If you run every question through these five steps, you will always have a next thing to say, which is most of the battle.

The five-step framework

1. Clarify the problem until you know exactly what you are building and for whom.
2. Estimate the scale so your design is anchored to real numbers, not vibes.
3. Sketch the high-level design end to end before you touch any single piece.
4. Go deep on the two or three components that actually matter for this problem.
5. Address the trade-offs: bottlenecks, failure modes, and what you would change at 10x.

Most interviews are 45 minutes. A rough budget is 5 minutes clarifying, 5 estimating, 10 on the high-level design, 15 to 20 going deep, and the rest on trade-offs and questions. Say this budget out loud if you like. Interviewers appreciate a candidate who manages their own time.

Step 1: Clarify before you design

The single most common way to fail is to start drawing boxes for the wrong system. "Design Twitter" can mean the read path for a timeline, the write path for posting, the follow graph, search, notifications, or all of it. You cannot build all of it in 45 minutes, and the interviewer knows that. They want to see you scope.

Ask about functional requirements first. What must the system actually do? For a URL shortener: shorten a long URL, redirect a short URL, maybe expiration and analytics. Write the agreed list down where you both can see it. Then ask about the non-functional requirements, because those are what shape the architecture:

• Scale: how many users, how many requests per second, read-heavy or write-heavy?
• Latency: does a redirect need to feel instant, or is a second acceptable?
• Consistency: if two people act at once, must they see the same thing immediately, or is a short delay fine?
• Availability: what happens if a component is down? Can the system degrade instead of failing?

Read-heavy versus write-heavy is the question that changes the most downstream. A URL shortener is overwhelmingly reads, so you optimize the redirect path with caching and replicas. A metrics ingestion system is writes, so you optimize for throughput with queues and batching. Get this straight early and half your later decisions make themselves.

Step 2: Estimate the scale

Estimation scares people, but interviewers are not checking your arithmetic. They are checking whether your design is grounded. A system for a thousand users and one for a hundred million are different systems, and saying so proves you understand that.

Keep the math crude and round aggressively. Suppose the interviewer says a hundred million daily active users, each making ten requests a day. That is a billion requests a day. Divide by roughly a hundred thousand seconds in a day and you get about ten thousand requests per second on average, with peaks maybe three to five times that. Now you know a single database is not going to serve reads directly, and you can say why.

Do the same for storage. A billion new records a year at a few hundred bytes each is a few hundred gigabytes a year. That fits on one machine, which tells you sharding is about read throughput here, not raw capacity. Numbers turn hand-waving into decisions.

Step 3: Sketch the high-level design first

Before you optimize anything, draw the whole request flow at a low resolution. Client, load balancer, application servers, database, and whatever cache or queue the requirements clearly demand. The goal is one coherent picture that satisfies the functional requirements, even if it would fall over at scale. You will fix that in step four.

Talk through a single request end to end. "A user posts a URL. It hits the load balancer, which routes to an app server. The server generates a short key, writes the mapping to the database, and returns the short URL." Then the read path: "A user hits the short URL, the app server looks up the key, and issues a redirect." Now the interviewer can see the skeleton, and every deeper conversation has a place to hang off.

Resist the urge to add every technology you know. A queue you cannot justify is a red flag, not a bonus. Add components when a requirement forces them, and be ready to say which requirement.

Step 4: Go deep where it counts

This is where the interview is won or lost, and where you get to show real engineering judgment. You do not have time to go deep on everything, so pick the two or three components that matter most for this specific problem and dig in. A few recurring themes:

Data model and the database choice. Sketch the tables or documents. Justify relational versus non-relational based on the access patterns you established, not on preference. If reads dominate and you need them fast, this is where read replicas and sharding enter the conversation, and where consistent hashing explains how you distribute data across nodes without reshuffling everything each time you add one.

Caching. For any read-heavy system, describe what you cache and where. Be specific about the layer, the eviction, and the invalidation, because "we'll add a cache" without those details is the answer of someone who has never operated one. I wrote a full breakdown of the caching layers from CDN down to the database if you want the mental model.

Asynchronous work. Anything that does not need to happen inside the request should not. Analytics, emails, and fan-out belong behind a queue. Explain the delivery guarantees you need and why, because message queues are where at-least-once delivery and idempotency suddenly matter.

Scaling the tier that will break first. Use your estimates to name the bottleneck. If it is read throughput, you reach for replicas and caching. If it is write throughput, you reach for sharding or a queue that batches. Tie it back to a number you calculated so the choice is defensible.

Step 5: Trade-offs, failure, and scale

No design is free, and the strongest signal you can send is naming your own design's weaknesses before the interviewer does. Pick the biggest one and address it.

Walk through what happens when a component fails. If the cache goes down, do requests fall through to the database or does the system crash? If a database node dies, is there a replica ready to take over, and how much data might you lose in the switch? This is where high availability and consistency models stop being buzzwords and become concrete choices about RTO and RPO.

Then talk consistency honestly. Most systems do not need strong consistency everywhere, and pretending they do makes designs slower and more fragile than they need to be. Say where eventual consistency is fine (a like count that lags by a second) and where it is not (a payment that must not double-charge). Understanding the CAP theorem and consistency models well enough to apply them selectively is what separates a senior answer from a memorized one.

Finish by naming what you would change at ten times the scale. Maybe the single write database becomes a bottleneck and you introduce sharding. Maybe you add a rate limiter to protect the system from abuse. You do not have to build it. You just have to show you can see around the next corner.

What interviewers are actually scoring

Behind the specific problem, the rubric is remarkably consistent across companies:

• Did you scope the problem, or start building blindly?
• Are your decisions justified by requirements and numbers, or by name-dropping?
• Can you go deep on at least one component with real detail?
• Do you see the failure modes and trade-offs, or present the design as flawless?
• Can you communicate clearly and take a hint without getting defensive?

That last one matters more than people expect. When an interviewer nudges you, it is almost always because they want to see you incorporate new information gracefully, not because you are wrong. Treat their questions as collaboration, restate what you heard, and adjust. A candidate who argues with every prompt reads as someone who will be hard to work with, no matter how good the design is.

How to practice

Reading about system design is necessary but not sufficient. The skill is verbal and improvised, so you have to practice it that way. Take a well-known product and give yourself 45 minutes and a whiteboard or a blank document. Talk out loud the entire time, even alone. Record yourself if you can stand it. The gap between what you think you explained and what you actually said out loud is where most of your improvement hides.

Work through the classics until the framework is automatic: a URL shortener, a rate limiter, a news feed, a chat system, a notification service. Each one exercises a different muscle, but you run all of them through the same five steps. Once the framework is reflexive, you stop trying to remember what comes next and start actually thinking about the problem, which is exactly where you want to be when the real interview starts.

The individual topics in this series go deeper on each building block the framework leans on, from load balancing to consistency to queues. Learn them as engineering first and interview answers second. The candidates who are hardest to stump are the ones who have actually built and broken these systems, because they are not reciting. They are remembering.