A system design interview asks you to design something like a link shortener in about 45 minutes, out loud, with someone who keeps asking "why?". You've seen only a few building blocks so far, and that's fine: the method doesn't depend on them. Learn it now, and every chapter after this one hands you another box to justify with it.

The shape of 45 minutes

Interviewers aren't looking for one right diagram. They watch how you get to one: whether you pin down the problem before solving it, size it with numbers, and can defend each choice. Most good interviews follow the same arc:

Say which phase you're in. "Before I draw anything, I'd like to pin down the requirements" tells the interviewer you have a plan. The example in this chapter is ink.ly, the link shortener Inkwell's founders want: the most common first question in these interviews.

Requirements first

Functional requirements are what the system does. Non-functional requirements are how well it does it: scale, latency, availability, consistency, durability. The second list decides the design far more than the first.

Ask about the parts that change the design: How many users? Read-heavy or write-heavy? Global? How fresh must reads be? What can be lost? Then write the answers down where both of you can see them. The rest of the interview keeps coming back to this table.

Estimates

Turn the requirements into numbers with the arithmetic from Estimation: users × actions ÷ seconds, rounding freely.

The numbers tell you what matters. 40 writes a second is nothing. 12 000 reads a second is about nine medium app servers before headroom, and more than the roughly 8 000 reads a second one medium database can serve. 3 TB fits on one database, so the data doesn't need splitting for its size. Say it out loud: "the hard part is the redirects at the peak, not the writes." You'll work this chain yourself at the end of the chapter.

API and data model

Name the calls before the boxes:

One choice here is a real tradeoff: a 301 (permanent) redirect may be kept by browsers indefinitely, which is fast but means edits and click counts can stop reaching you; a 302 (temporary) redirect isn't kept unless the response says it may be, so the next click sees an edit. The Cache-Control header settles how long either is kept: bit.ly sends a 301 with a max-age of a minute and a half. ink.ly allows edits, so a 302, or a 301 with a short max-age.

Every lookup is by code, and nothing joins or searches across links: code → long URL, owner, created at. One table keyed by code holds it. Later chapters show stores built for exactly this shape; whichever you pick, say why.

High-level design

Start with the simplest boxes that meet the functional requirements, then let the numbers add more. For ink.ly that start is the design from your first chapters:

The first sketch: it creates, redirects and edits links. Now check it against the numbers.

Then hold it against the estimates and say where it breaks. The app servers scale out behind the load balancer. The database can't serve 12 000 redirects a second, and readers on other continents pay the distance on every click. Those two gaps are what the next boxes are for, and each later chapter gives you one: a copy of the hot data in memory, a server near the reader, more copies of the database. A box you can't justify from a requirement or a number is a box to remove.

Deep dives

After the main design, the interviewer picks the hard parts and pushes. For each one, give two or three options, pick one, and say what it costs. Don't defend a choice to the end: if they point out a cost you missed, weigh it and say whether you'd switch.

The same few questions come up for almost every system. Each case study at the end of the roadmap runs through them for one product.

Talking about tradeoffs

Every answer has the same shape: I'd choose X, because of requirement Y; it costs Z; if W changed, I'd switch to V.

Common mistakes: drawing before asking, designing for a scale nobody mentioned, naming a technology without the reason, and never mentioning what happens when something fails.

Using the case studies

The last chapters are whole systems: a news feed, notifications, payments, file sharing, reactions, chat, and ink.ly itself. Each opens with the requirements and the numbers, the way an interviewer would hand them to you. Get more from them by doing each phase yourself before reading on: write the requirements, work the estimates, sketch the boxes, then compare. Time yourself against the 45 minutes, and talk out loud even when you practise alone; the habit of saying the reason with the choice is what the interview tests.

Come back to this chapter before each case study. The phases don't change; only the system does.

Once this chapter is done, every case study can also be tried cold, as a mock interview: open it from Interview practice before you reach its chapter, and you get a one-line brief, questions to put to the interviewer, 45 minutes and one run, then a review against a strong answer. Try ink.ly that way now for a baseline, and again when you reach its chapter. Interview practice also has four mock interviews on paper, for classic questions the simulator doesn't run (a rate limiter, ticket booking, search suggestions and nearby places): the same 45 minutes and questions, with the design written out and a reference design to hold it against.

In the wild

The ideas in this chapter, and where you'll meet them in real systems and interviews:

Your practice

Estimate ink.ly: work the chain from the requirements to requests a second and storage, the way you would on a whiteboard. Every step within a factor of two finishes the chapter. You'll build ink.ly for real once you have its boxes, in the URL Shortener case study.