A 45-minute framework for system design interviews

System design interviews feel open-ended because they are. There's no single correct answer, the problem is deliberately vague, and the interviewer will change the requirements halfway through. What they're really evaluating is how you handle that: whether you scope before you build, whether your choices have reasons, and whether your design survives pressure.

A consistent structure helps more than memorised architectures. Here's one that fits a 45-minute round, with roughly how long to spend on each part.

The shape of the round

The times are a guide, not a script. Interviewers often steer you toward the part they care about, and following them is the right call.

1. Requirements: the part most people rush

Before drawing anything, ask questions until you can write down two short lists.

Functional requirements are what the system does. For a URL shortener: create a short link, redirect a short link to the original URL, and perhaps custom aliases or expiry. Pick the core two or three and say the rest are out of scope unless the interviewer wants them.

Non-functional requirements are how well it does it: scale, latency, availability, consistency, durability. These drive almost every design decision, so make them explicit:

• How many users or requests? Is traffic read-heavy or write-heavy?
• What latency is acceptable on the critical path?
• Is it acceptable to briefly show stale data, or does every read need the latest write?
• What happens if the system is down for a minute? An hour?

Write both lists where the interviewer can see them. You'll refer back to them for the rest of the interview, and so will they.

A good test: if you can't explain why a component is in your design by pointing to a requirement, it probably shouldn't be there.

2. Estimates: rough numbers, said out loud

You don't need precision. You need the order of magnitude, because it tells you whether one database will do or whether you need to partition.

A quick sequence that works for most prompts:

1. Requests per second. Daily volume ÷ ~100,000 seconds per day gives a rough average. Multiply by a peak factor of 2–10×.
2. Read/write ratio. Most consumer systems read far more than they write.
3. Storage. Records per day × size per record × retention period.
4. Bandwidth, if large payloads (images, video) are involved.

For example, 100 million redirects a day is roughly 1,000–1,200 reads per second on average and perhaps 5,000–10,000 at peak. That's comfortably cacheable, which tells you the redirect path should hit a cache first.

Say the numbers as you go, and say what they mean for the design. The conclusion matters more than the arithmetic.

3. API and data model

Define the handful of endpoints or operations the system exposes, and the main entities it stores. Keep it brief:

POST /links        { url, alias? }  -> { code }
GET  /{code}       -> 301 redirect

links: code (PK), url, owner_id, created_at, expires_at

This step catches misunderstandings early and gives you vocabulary for the rest of the interview.

4. High-level design

Now draw the system: clients, load balancer, services, data stores, caches, queues. Walk the interviewer through the main request paths, one at a time, against your requirements.

Two habits help here:

• Start simple. A single service and a single database, then evolve it. Jumping straight to fifteen microservices suggests you're reciting rather than designing.
• Name the choice and the reason. "I'll use a key-value store for links because access is always by code and we need fast point reads" is much stronger than "I'll use DynamoDB."

5. Deep dive: depth beats breadth

Pick the hardest or most interesting component (or let the interviewer pick) and go deep. For a URL shortener that might be generating unique codes without collisions across many servers. For a chat system, it might be message ordering and delivery guarantees. For a rate limiter, it's shared state across nodes.

In the deep dive, interviewers look for:

• Alternatives considered, and why you chose one
• Concrete failure modes and how you handle them
• Awareness of what your choice costs: latency, complexity, consistency, money

Going deep on one component shows more than skimming ten.

6. Pressure test: expect the follow-ups

Once your design hangs together, the interviewer will try to break it. Common follow-ups:

• "Traffic just grew ten times. What breaks first?"
• "Your cache cluster went down. What does the database see?"
• "Two requests for the same user arrive on different servers at the same time. What happens?"
• "Product wants this in three regions. What changes?"
• "How would you know this system is unhealthy?"

There's no need to have a perfect answer ready. Reason out loud: identify the bottleneck, propose a change, and say what the change costs. Revising your design in response to new information is exactly what they want to see. Defending a broken design is not.

Mistakes that cost the most

• Designing before scoping. Ten minutes into the wrong system is hard to recover from.
• Components without reasons. Every box should trace back to a requirement.
• Ignoring the interviewer's hints. If they ask about a component twice, that's where they want you to go.
• Silence. If you need to think, say what you're thinking about.
• Never mentioning tradeoffs. Every decision has a cost. Naming it is a signal of seniority.

How to practise

Reading about system design builds vocabulary. Passing the interview takes practice under realistic conditions: out loud, against the clock, with someone pushing back on your choices. Run the framework on a new prompt every few days, and rerun the ones that went badly.

It also helps to watch the process from the other side. In Hardmode's Switch seats mode you play the interviewer while an AI candidate works through a design, so you can see how a strong answer is structured before you try one yourself.