A 45-minute interview framework

Think of it like this

Analogy

A system design interview is like an architect's first meeting with a client. A good architect doesn't start sketching a mansion. They ask who will live there, the budget, the plot, what matters most. Then they draw a rough floor plan, talk through the important rooms in detail, and finish by pointing out what could go wrong and what they'd revisit later.

The problem it solves

Interview questions like “design Twitter” are deliberately huge and vague, and 45 minutes go fast. Candidates who know the material still fail because they dive into details too early, run out of time before the core design, forget to justify choices, or design for the wrong scale. Interviewers mostly evaluate how you think: structure, trade-offs and communication.

A real example

Example

45 minutes: “Design a ticket booking system”

Minutes 0–5: you ask questions. Concerts or cinemas? How many events and users? Do people pick exact seats? You agree on booking seats for big concerts, with sales that start at a fixed time.

5–10: rough numbers. 1 million people arriving within minutes of a sale opening, but only 50,000 seats. Reads hugely outnumber bookings.

10–25: a high-level design: clients, load balancer, an event service with cached seat maps, a booking service, a database, and a waiting room to let people in at a steady rate.

25–40: a deep dive on the hard part, which is two people grabbing the same seat. You use short seat holds with an expiry and a conditional update when the booking is confirmed.

40–45: what fails and how you'd notice, then a quick summary.

How it works

Step 1. Requirements (about 5 minutes)

Ask, then write the answers down where the interviewer can see them.

• Functional: the 3–4 core features. Explicitly put the rest out of scope (“I'll skip direct messages unless you'd like them”).
• Non-functional: number of users, read/write ratio, latency target, availability, consistency needs, data retention, regions.
• Priorities: “Is it more important that feeds are fresh or that they load fast?”

Step 2. Estimates (about 4 minutes)

Quick, rounded math (lesson 34): requests per second (QPS) average and peak, storage per year, bandwidth. The goal isn't precision; it's knowing whether this is one server or a thousand, and whether it's read- or write-heavy. Say what each number implies.

Step 3. API and data model (about 6 minutes)

• A few key endpoints with inputs and outputs (POST /posts, GET /feed?cursor=).
• The main entities and how they're accessed. Choose storage from the access patterns (lesson 9), and say the shard key if it's large.

Step 4. High-level design (about 10 minutes)

Draw the request path for the main use cases: clients, load balancer, services, cache, database, queue, storage, CDN. Walk through one read and one write end to end. Keep it simple; a working simple design beats an incomplete complex one.

Step 5. Deep dives (about 15 minutes)

Pick the 2–3 hardest or most interesting parts, or follow the interviewer's lead:

• The bottleneck component at your estimated scale (the feed generator, the matching service).
• Data partitioning and hot keys.
• Consistency: where it must be strong, where eventual is fine.
• Caching strategy and invalidation.
• Specific algorithms (ID generation, rate limiting, geo search).

For each choice, state the alternative and why you didn't pick it.

Step 6. Wrap-up (about 5 minutes)

• Single points of failure and failure handling: what if the cache, a region or a dependency fails?
• Bottlenecks at 10× scale and how you'd evolve.
• Monitoring: the key metrics and alerts.
• What you'd do with more time.

Habits that score well

• Think out loud and check in: “Does this level of detail work, or should I go deeper on storage?”
• Name trade-offs every time you choose something.
• Use numbers from your estimates to justify components.
• Start simple, then evolve, the same story as lesson 1.
• Don't name-drop. “A partitioned log like Kafka, because we need replay and ordering per user” beats “we'll use Kafka”.

Common mistakes

• Designing before clarifying requirements.
• Spending 20 minutes on one component.
• Over-engineering (microservices, multi-region active-active) for a problem that doesn't need it.
• Never mentioning failure, consistency or monitoring.
• Going silent while thinking.

Trade-offs

What you gain

• A fixed structure means you never run out of time before the core design.
• Requirements and estimates make your later choices easy to justify.
• Interviewers can follow your reasoning and steer you.

What it costs you

• Following the template too rigidly can ignore what the interviewer wants to explore.
• Time boxes vary: some interviews are 35 minutes, some focus almost entirely on one deep dive.

When not to use it

• If the interviewer clearly wants to jump into a specific component, follow them; the framework is a default, not a rule.
• Don't spend long on estimates when the interviewer says the numbers don't matter.

In the cloud

Reference architecturesEvery major cloud sells this as a managed service, so you configure it rather than build it.

AWS1

• AWS Architecture Center (opens vendor docs)

  Reference architectures, the Well-Architected Framework and design patterns.

Azure1

• Azure Architecture Center (opens vendor docs)

  Reference architectures, cloud design patterns and the Well-Architected Framework.

Google Cloud1

• Google Cloud Architecture Center (opens vendor docs)

  Reference architectures and the Google Cloud Well-Architected Framework.

Interview questions

Try answering out loud first, then open the model answer.

The interviewer says, “Design YouTube.” What's your first minute like?+

Model answer

“Before I start, can I check the scope? I'll focus on uploading videos, watching them, and a basic home page, and leave out comments, live streaming and monetization unless you want them. Roughly how many daily users should I assume, how many uploads per day, and is this global? I'll assume playback start time and availability matter most and that a view count can be slightly delayed. Does that match what you have in mind?” Then I'd write those down and move to estimates.

How do you handle a question you don't know the answer to in an interview?+

Model answer

Say so honestly, then reason from first principles. For example: “I haven't designed a geo index before, but here's how I'd think about it: we need to find drivers near a point quickly, so I'd bucket the map into cells and look up the user's cell and its neighbors.” Interviewers value structured reasoning and awareness of trade-offs more than recall.

How do you decide what to deep-dive into?+

Model answer

Pick the parts that are hardest at the estimated scale or most specific to this problem: the component that becomes the bottleneck, the part with the trickiest correctness requirement, or what the interviewer reacts to. For a chat app that's message delivery and ordering; for a URL shortener, ID generation and caching; for ride sharing, location indexing and matching. I usually ask: “I think the two most interesting parts are X and Y; which would you like me to go deeper on?”

Quiz

Pick an answer to see whether it’s right and why.

1. 01What should you do in the first five minutes?

   Start drawing boxes immediatelyAsk questions to pin down requirements, scale and prioritiesPick your favorite database
2. 02The interviewer asks why you chose a NoSQL store. What makes a strong answer?

   It's what big companies useName the access pattern and scale that drove the choice, and what you gave up for itSay any database would work
3. 03You have 10 minutes left and haven't discussed failures. What do you do?

   Ignore it, nobody asksWalk through what happens when key components fail, and how you'd detect and recoverStart over with a new design
4. 04The interviewer asks you to go deep on one component. How do you choose?

   Pick the easiest onePick the part most likely to break at scale, or the one they've hinted atPick one at random
5. 05You don't know a technology the interviewer mentions. What's best?

   Say so, then reason from first principles about what it must doPretend you know itChange the subject
6. 06Why say your assumptions out loud?

   It fills timeIt's required by the rulesThe interviewer can correct you early, and they see how you think

0 of 6 answered

Key terms

Functional requirement

Something the system must do, such as "users can upload a photo".

Non-functional requirement

How well the system must do it, such as speed, uptime, cost or security targets.

QPS

Queries (or requests) per second, the usual unit for load.

Single point of failure

One component whose failure takes the whole system down.