System Design Interview Template: A 45-Minute Step-by-Step Framework

“Design a URL shortener.”

Twelve minutes later you’ve drawn three databases, a queue and something labeled “magic,” and the interviewer asks, very politely, how many reads per second you’re designing for. You never asked. Now you’re doing math backwards while the clock keeps going.

That’s the most common way system design rounds go wrong. Not a lack of knowledge. A lack of order. People who know plenty about caching still skip requirements, burn fifteen minutes on estimates, or never reach the deep dive.

A system design interview template fixes the order problem. It won’t design the system for you, but it frees your head for the actual problem. Below is the template I’d use for a 45-minute round, minute by minute, with a URL shortener worked through each step, phrases that keep you moving, and what changes by level.

Times are guides, not rules. Some companies run longer design rounds, and a good interviewer will steer you. When they do, follow them.

Why bother with a template

Interviewers in a design round are usually judging a handful of things. Did you find out what to build before building it? Did you end up with something that would work? Could you go deep on one hard part? Did you talk about trade-offs instead of pretending there was one right answer? And could they follow your thinking the whole way?

Wing it and you’ll usually hit three of those. The template is there so you hit all five, even on a bad day.

Bonus: when you know the steps, silences get shorter. There’s always a next thing to say, even if it’s “let me check my numbers.”

The 45-minute template at a glance

The seven steps and roughly how long each should take in a 45-minute round.

Got an hour instead of 45 minutes? Don’t spread the extra time evenly. Pour most of it into the deep dive, since that’s the step people run out of clock on and usually where senior candidates pull ahead.

Minutes 0-5: requirements and scope

Start by asking, not drawing.

Features come first, and keep it to two or three. For the shortener that’s turning a long link into a short one and sending people to the right place when they click it. Custom aliases and expiry, maybe. Read the list back and wait for the nod.

Then the things that aren’t features but shape everything anyway: how many users, how fast a redirect has to feel, what happens if links go dead for a minute, whether a brand-new link has to work everywhere right away. Honestly, these answers move the design more than the feature list does.

The one people skip is saying what you won’t build. “I’ll leave out user accounts and the analytics dashboard unless you want them.” Five seconds, and it saves you a twenty-minute detour nobody asked for.

A clarifying exchange might sound like this (illustrative):

You: “Before I design anything, can I check scope? I’m thinking create and redirect are the core, custom aliases are nice to have, and analytics is out unless you want it. Roughly how many new links a month are we expecting?”

Interviewer: “Say 100 million new links a month. Reads are much heavier than writes.”

You: “Got it. And for redirects, I’m assuming low latency and high availability matter more than every region seeing a new link that same second. Fair?”

That’s about a minute of talking, and you now have numbers, a read/write shape and a consistency choice.

Five minutes of questions turn a vague prompt into a few requirements you can actually design for.

Minutes 5-10: rough numbers

Only calculate what changes your design. This isn’t a math test, and nobody’s impressed by six decimal places.

Use round numbers. A day has 86,400 seconds; call it 100,000. A month is about 2.6 million seconds. So for the shortener:

100 million new links a month is roughly 40 writes per second. If reads are 100 times heavier, that’s around 4,000 redirects per second on average, more at peak. If each record is about 500 bytes and we keep links for five years, that’s 6 billion rows and about 3 TB. These are assumptions for the example, and you should say so out loud as you make them.

What do those numbers tell you? Writes are tiny. Reads matter. 3 TB fits on a small cluster but you’ll probably want to split it. A cache in front will take most of the read load. That’s the whole point of the estimate: three design decisions in five minutes. Our guide to estimation and Fermi questions has more practice problems.

Minutes 10-15: API and data model

Write the API before the boxes. It forces you to be concrete about what the system does.

For the shortener, two endpoints carry the whole thing: POST /urls takes a long URL and optional alias or expiry, and returns a short code. GET /{code} returns a redirect.

Here’s a small decision worth saying out loud: 301 or 302? A 301 is permanent, so browsers cache it and stop asking you, which saves load but means you lose click counts. A 302 is temporary, so every click comes back through you. Picking one and saying why is exactly the kind of trade-off interviewers want to hear early.

The data model is one main table: code (the key), long URL, created time, expiry, owner. Lookups are always by code, so a key-value store fits well. If you go relational, say why. For more on endpoint design, see API design interviews.

Minutes 15-25: high-level design

Draw the simplest thing that works, end to end, and talk while you draw. Client, load balancer, a few stateless app servers, a cache, the database. One path for creating a link, one for redirecting.

Boring is good here. My honest take? The candidates who start with Kafka and three microservices usually end up apologizing for them later. Get a working design on the board first, then let the numbers tell you where it’ll break.

Narrate each request as it travels: “A redirect hits the load balancer, goes to any app server, which checks the cache by code. On a hit we return the redirect. On a miss we read from the database, fill the cache, then redirect.” The interviewer should be able to follow without squinting at your boxes.

Then check it against the requirements from minute zero. Each should map to something on the board.

Minutes 25-37: the deep dive

This is where most of the score lives. Pick one or two parts that are actually hard, or ask: “I could go deeper on how we generate short codes, or on caching and hot links. Which is more interesting to you?”

For the shortener, code generation is the classic. Here are your options, and you should name more than one:

Hash the long URL and take the first seven characters. Simple, but collisions happen and you need to check for them. Use a counter and encode it in base62 (a to z, A to Z, 0 to 9). Seven characters gives 62 to the power of seven, about 3.5 trillion codes, which is plenty, but a single counter is a bottleneck and the codes are guessable. Or hand each app server a block of IDs from a small coordination service, so servers can create codes without talking to each other on every request.

I’d go with the ID blocks, and I’d say why: no collision checks, no single hot counter, and a server that crashes just wastes part of its block. Then admit the cost. Codes are roughly sequential, so if guessability matters you’d add some scrambling.

Pick the one part of the system most likely to break and zoom in on it.

If there’s time, take the second deep dive: caching. Most redirects hit a small set of popular links, so a cache with sensible expiry absorbs most reads. Then talk about what happens when one link goes viral and a single cache key gets hammered. Our posts on caching strategies and sharding and replication go further on both.

Minutes 37-42: trade-offs and failure modes

Don’t wait to be asked. Walk your own design and break it.

What’s the single point of failure? (The ID coordination service, so run more than one and give servers big enough blocks to ride out a short outage.) What happens at 10 times the traffic? (Reads scale with more cache and app servers, writes are still small.) Where did you choose availability over consistency? (A new link might take a moment to show up in every region, which you agreed was fine back in minute three.)

Then say what you’d do differently with more time. It shows judgment, not weakness. For a longer list of what candidates miss here, see system design mistakes to avoid and our guide to architecture trade-off discussions.

Phrases that keep the interview moving

None of this works if you sound like you’re reading a checklist off the ceiling. So here are lines I’d actually say out loud. Steal them, then bend the wording until it sounds like you:

• “Before I design anything, can I check the scope?”
• “I’ll use round numbers so the math stays quick.”
• “Let me get something simple working end to end, then find where it breaks.”
• “There are two ways I could go here. Here’s the one I’d pick and why.”
• “I could go deeper on X or Y. Which would you rather see?”
• “Let me check this against the requirements before I move on.”
• “If I had another ten minutes, I’d look at…”

That last one gets overlooked. At minute 43 you can’t start a new section, but you can still show the interviewer you knew where the design was weak.

The worked example in one picture

Here’s where the URL shortener ends up after 40 minutes:

The final design: a cached read path, a simple write path, and ID blocks so servers don’t fight over one counter.

And here’s how you might sum it up in about ninety seconds at the end, said the way you’d actually say it (illustrative):

“So, quick recap. We need to create short links and redirect them, around 40 writes and a few thousand reads a second, and redirects need to be fast and always up. Writes go through stateless app servers into a key-value store sharded by code. Codes come from ID blocks each server grabs from a small coordination service, encoded in base62, so no collisions and no hot counter. Reads check a cache first, which takes most of the load because popular links are a small set. I chose 302 redirects so we keep click counts, and click events go on a queue so analytics never slows a redirect down. The weak spot is a viral link hammering one cache key. Next step there would be replicating hot keys or caching them on the app servers for a few seconds.”

What changes by level

Same template at every level. What shifts is how much of it the interviewer expects you to do without help, and companies draw these lines differently, so take this as a rough pattern rather than anyone’s official rubric.

If you’re early in your career, you might get a lighter design round, or none at all. When you do get one, a design that works plus clear talking gets you a long way, and nobody expects you to know how to shard a database you’ve never run. Mid-level, they want every step covered and one real deep dive without being dragged there. Senior is where it flips: you’re the one driving, you point out the bottleneck before they ask, you compare two options with actual numbers, and you bring up failure modes because you’d be the one paged for them. Staff conversations wander further out, into how the thing grows over a few years, what it costs to run and which teams would own which parts.

Design rounds sometimes come with a project question too: “Tell me about a system you designed.” A short STAR answer for that might sound like this (fictional):

Situation: “Our notification service sent everything through one database table used as a queue, and it fell behind every time marketing sent a big campaign.”

Task: “I was asked to fix the backlog without a full rewrite, since we had one quarter.”

Action: “I measured first. The table was fine for normal load but lock contention exploded at campaign peaks. I proposed moving campaign sends to a separate queue with its own workers, keeping the old path for password resets and other urgent messages. I wrote the design doc, got two teams to agree on the split, and built the campaign path myself.”

Result: “Campaign days stopped delaying password resets, which was the complaint that started all this. If I did it again, I’d have split urgent and bulk traffic from day one.”

Our guides to the Google, Meta and Amazon loops cover their design rounds, and top FAANG system design questions gives you more prompts to run the template on.

Practicing with OfferBull

Here’s the part people underestimate. The diagram is maybe half the round. The other half is talking: asking scoping questions without sounding lost, explaining why you picked 302 over 301, and not freezing when someone asks “why not just use a bigger database?”

That talking half is what OfferBull is for. It’s an AI mock interview app for iOS and Android, and the interviewer asks its questions out loud, so you practice answering in your own voice instead of in your head. Paste the job description or upload your resume and the questions get tailored to the role. Then it follows up on whatever you said (and on what’s on your resume), which is good training for those “okay, but why that?” moments. For the project questions, it can show answer suggestions and STAR structures while you practice. You can do all of it in English or Chinese.

It’s a rehearsal tool, full stop. In the real interview it’s you, the interviewer and a whiteboard.

Start an AI mock interview

FAQ

What if the interviewer pulls me off the template? Let them. If they jump straight to the database in minute four, they’re telling you what they care about, and arguing with that is a bad look. Just circle back to whatever you skipped before the clock runs out.

Do my numbers have to be right? Not really. Round numbers and assumptions you say out loud are fine. What they want to see is the number changing a decision, like “writes are tiny, so one primary is plenty for now.”

My round is an hour, not 45 minutes. Now what? Same steps. Spend the extra on the deep dive and the trade-offs. Please don’t spend it on requirements.

Which prompts should I practice first? I’d start with a URL shortener, a chat app, a news feed and a rate limiter. Between those four you’ll bump into caching, queues, fan-out and consistency, which covers a surprising amount of what gets asked.

---

Practice This Out Loud

Tonight, if you can: set a 45-minute timer, pick one of those four prompts and talk through all seven steps with your phone recording. No looking things up. When you play it back, check one thing only. Did you get to the deep dive by minute 25? Most people don’t, the first few times. Once you’ve done it twice in a row, try the same prompt in a voice mock interview that pushes back with follow-ups. → Practice Now