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. This guide covers what the round is, how long it lasts, a framework that fits a 45-minute slot, and how to prepare and practise so the framework is second nature by the day itself.

What a system design interview is

You're given a short, vague prompt ("design a URL shortener", "design a notification service", "design the backend for a ride-sharing app") and a shared whiteboard or drawing tool. Over the next 45 to 60 minutes you turn that prompt into requirements, a rough sense of scale, an architecture, and a deeper design for the hardest part, while the interviewer asks questions and changes the constraints.

It usually appears for mid-level roles and above, and it carries more weight the more senior the role. For a mid-level engineer, a workable design with sensible components is a good result. For a senior or staff engineer, the interviewer expects you to lead: spot the hard part early, raise tradeoffs and failure modes before being asked, and talk about how the system is run, monitored, and rolled out.

How long a system design interview is

Most system design rounds are 45 to 60 minutes. Take off five minutes for introductions and five for your questions at the end, and you have 35 to 50 minutes of actual design. That's less time than it sounds, which is why structure matters: without it, the requirements discussion drifts, the high-level design takes half an hour, and the deep dive (where most of the signal is) never happens.

The framework below assumes about 45 minutes of design time. In a shorter slot, compress the requirements and estimates; don't skip them.

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 naming a product.

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.

Common traps

• 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 prepare for a system design interview

Preparation has two parts: the building blocks you reason with, and the habit of running the framework under time pressure. Most people overdo the first and skip the second.

Learn the building blocks, and why each exists

You need a working understanding of a fairly short list of components and ideas:

• Load balancing and stateless services
• Caching: where a cache sits, what it costs when it's cold or stale, and eviction
• Databases: relational versus key-value versus document stores, indexes, replication, and partitioning (sharding)
• Queues and streams: decoupling producers from consumers, retries, and delivery guarantees
• Consistency: what "eventually consistent" means for a user, and when you need stronger guarantees
• Failure: timeouts, retries with backoff, idempotency, and what happens when a dependency is slow rather than down

For each one, be able to say what problem it solves, what it costs, and when you wouldn't use it. That last part is what turns a list of components into a design.

Calibrate to the role

Read the job description for the level and the domain. A posting that talks about event processing at scale is hinting at queues, ordering, and idempotency; one about a consumer product with global users is hinting at caching, latency, and regions. Our guide to preparing from the job description covers how to turn a posting into specific practice prompts, including system design ones.

How long to prepare

It depends on where you're starting. If you design and run systems at work, a couple of weeks of regular practice sessions is often enough to get the structure fluent. If system design is new to you, give yourself longer: several weeks of learning building blocks alongside practice, rather than reading everything first and practising at the end. Short, frequent sessions beat a single weekend of cramming, because what you're building is a habit, not a store of facts.

How to practise system design

Reading about system design builds vocabulary. Being ready for the round takes practice under realistic conditions: out loud, against the clock, with someone pushing back on your choices.

• Run the whole framework, timed. Set a 45-minute timer and go from requirements to pressure test. Most people find their time vanishes into the high-level design the first few times; the timer shows you where.
• Talk out loud, even alone. Explaining while designing is a separate skill from designing. If you only think silently, the interview is the first time you'll do both at once.
• Rotate prompts across types. Mix read-heavy systems (a news feed), write-heavy ones (a metrics pipeline), and coordination problems (a rate limiter, a booking system). Each stresses a different part of the toolkit.
• Rerun the ones that went badly. A second attempt at a prompt you struggled with teaches you more than a first attempt at a new one. Do it a few days later, from a blank page.
• Get pushback. The pressure-test phase is the hardest to practise alone. A friend who asks "what breaks first?" at the worst moment, or any interviewer that changes the requirements mid-design, is worth more than another solo run.

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. When you're ready to be on the other side of the table, the system design round runs the full 45–60 minutes with a scratchpad and an interviewer that changes the requirements.

Updated 21 October 2026