A System Design Interview Template

Imagine you walk into an interview and they say “Design Twitter.” Then next week, a different one says “Design Uber.” And the week after, “Design a chat app.” Different problems, right?

• Here’s the secret nobody tells you at first.
• You don’t need a fresh plan for each one.
• You need one template you can run on any “design X” question.

So in this lesson we’re going to build that template. It’s a fixed set of steps, in a fixed order, that you follow every single time. Memorize the steps once, and you’ll always know what to do next, no matter what they ask.

🎯 Why Use a Template

A system design question is open-ended and a little scary. When the pressure hits, your mind can go blank. So you want something steady to lean on.

• A template is just a fixed checklist of steps you walk through in order.
• It keeps you calm, because you always know what comes next.
• It keeps you complete, because you won’t forget a whole part of the problem.

Think of it like a pilot’s pre-flight checklist. Even experienced pilots use one, not because they’re forgetting how to fly, but because a checklist makes sure nothing important gets skipped under pressure. Your template does the same job in the interview room.

This template builds directly on the The System Design Interview Process, which explains the why behind each step in more depth. And if you want to see what goes wrong without a plan, the same lesson lists the common mistakes people make. Here we’ll keep it tight and reusable, like a card you can keep in your pocket.

🗺️ The Template at a Glance

Before we walk through each step, here’s the whole thing in one picture. Every “design X” question follows roughly this same path, top to bottom.

And here’s the same flow as a checklist, with what you do at each step and a rough time budget. A system design interview usually runs about forty-five minutes, so the minutes below are a guide to keep you moving.

Keep this map in your head. Whenever you feel lost in the middle of an interview, just ask yourself “which step am I on?” and move to the next one. Now let’s walk through each step.

1️⃣ Clarify Requirements

This is the step everyone wants to skip, and skipping it is the quickest way to design the wrong thing. So slow down right here.

• Don’t start drawing boxes the second they finish the question.
• “Design X” could mean a hundred different things, so your first job is to shrink it down to something you can actually build.
• You do that by asking questions, the way a real engineer would on day one of a project.

The questions split into two kinds. First, the functional requirements, which are the features, what the system actually does for the user.

• Can users post things? Can they search? Can they follow each other?
• Are we building everything, or just the core flow?

Then the non-functional requirements, which aren’t features but qualities the system must have, like how fast or reliable it is.

• How many users are we expecting? Thousands, or billions?
• Is it okay if data takes a moment to show up, or must it feel instant?

Once you’ve asked a few, say the scope out loud, like “Okay, so let’s focus on posting and reading for a large number of users, and skip search for now.” For the deeper version of this step, see Clarify the Requirements.

2️⃣ Estimate Scale

Now that you know what you’re building, get a rough feel for how big it is. This is back-of-the-envelope estimation, which just means quick math you could do on the back of an envelope, no calculator needed.

• The point isn’t to be exact, nobody expects perfect numbers.
• The point is to learn whether you’re building for a small crowd or a massive one, because that changes everything.

A few quick numbers are worth a guess.

• Users. Roughly how many people use it per day? This sets the overall size.
• Reads vs writes. Are people mostly reading data or writing it? On most apps, way more people read than write, and that tells you to make reading fast. QPS, short for queries per second, is just how many requests hit the system each second.
• Storage. Roughly how much data piles up over time? Lots of data means you’ll need serious storage, and that shapes the design.

Round everything to easy figures, say it out loud, and move on. The estimate is a compass, not a destination. For the full walkthrough, see Estimate the Scale.

3️⃣ Define the API

Before you draw any servers, nail down what the system actually offers. The cleanest way is to list the main API endpoints. An API is just the set of requests a client can send to your system, like the menu of things it can ask for.

• This turns fuzzy features into concrete actions.
• Each endpoint maps to one thing a user can do.

For a simple posting app, the core API might look like this.

createPost(userId, content)   → returns postId
getFeed(userId)               → returns list of posts
followUser(userId, targetId)  → returns ok

Let’s read what we just wrote.

• createPost is the write path, a user sends content and we hand back an ID.
• getFeed is the read path, the one most people will hit, so it has to be fast.
• followUser shapes who sees what later on.

See how just listing three endpoints already hints at a heavy read path and a lighter write path? For more, see Define the API.

4️⃣ High-Level Design

Now you finally get to draw the boxes. The high-level design is a simple diagram of the main pieces and how a request flows through them. Start basic, you can always add detail later.

• Don’t try to draw the perfect final system in one go.
• Put down the core components first, then walk a request through them out loud.

Most web systems share the same handful of building blocks.

• Client. The user’s phone or browser, where requests start.
• Load balancer. A traffic cop that spreads incoming requests across many servers so none gets overwhelmed.
• App servers. The machines that run your actual logic.
• Database. The organized store that holds your data.
• Cache. A small, super-fast store that keeps popular data handy so you skip the slow database when you can.

Here’s how they connect for a typical request.

Now walk the main flow out loud. For reading a feed: the client asks the load balancer, which picks an app server, which checks the cache first, and only hits the database if the cache doesn’t have it. Narrating the path like this is half the interview.

5️⃣ Deep Dive

Your high-level design is on the board. Now the interviewer usually says “Tell me more about X.” This is the deep dive, where you zoom into one or two pieces and get specific.

• You won’t have time to go deep on everything, and that’s fine.
• Pick the parts that matter most, or the part the interviewer points at.
• Going deep on one thing shows real understanding, far more than staying shallow on ten things.

What you pick depends on the system. Some common deep-dive topics.

• Database choice. Will you use a SQL database, which keeps data in strict tables with clear relationships, or a NoSQL one, which is more flexible and often scales out more easily? Say why you picked one for this case.
• Caching. What exactly do you cache, and when do you clear it out? Caching the most-read data usually makes sense, since the same items get hit over and over.
• A tricky component. Maybe how the feed gets built, or how large files get stored and served. Pick the hard part and explain it.

The key move is to justify every choice. Don’t just say “I’ll use NoSQL.” Say “I’ll use NoSQL here because our data is simple and we need to scale to huge numbers easily.” The reason is what they’re listening for.

6️⃣ Bottlenecks and Trade-offs

No design is perfect, and good engineers know it. So here you point out where your own system would struggle at scale, then say how you’d fix it. A bottleneck is the part that gets overwhelmed first as traffic grows, like a narrow doorway in a crowded hall.

• Finding your own weak spots is a strong signal.
• For each weak spot, name a fix, and be honest that the fix has a cost too.

Here are the usual tools you reach for, and what each one buys you.

• Caching. Keep hot data in fast memory so the database isn’t overloaded. The cost is that cached data can go stale, showing slightly old info.
• Replicas. Keep extra copies of the database so reads spread across them. Great for read-heavy systems, but keeping copies in sync adds complexity.
• Sharding. Split one giant database into smaller chunks so no single machine holds it all. It scales well but makes some queries trickier.
• Queues. Put slow jobs into a waiting line handled in the background, so the user isn’t stuck waiting. It adds moving parts, but keeps the app fast.

The pattern is always the same. Name the bottleneck, name the fix, name the cost. For the deeper versions, see Bottlenecks and Trade-offs.

7️⃣ Wrap Up

When you’re near the end, don’t just stop talking. Spend a minute pulling it all together.

• Summarize the design in a few sentences, the main pieces and how a request flows.
• Restate the big trade-offs you made and why.
• Name what you’d improve with more time, like “I’d add monitoring” or “I’d shard the database as we grow.”

That last bit matters a lot. Saying what you’d do next shows you know the design isn’t finished and that you’re thinking ahead. It ends the interview on a strong, senior note instead of a sudden silence.

🧩 Keep It a Conversation

Here’s the trap with a template. It’s there to guide you, not to turn you into a robot reading a script.

• Don’t recite the steps out loud like a checklist you’re ticking off.
• Adapt to the interviewer. If they jump ahead to the deep dive, follow them there, then loop back.
• Listen for hints. They often nudge you toward what they want to hear, so take the nudge.

Think of the template as the structure in your head, and the conversation as what actually happens in the room. You hold the steps quietly, and you bend the order when the interviewer leads. The steps keep you complete; the conversation keeps you human.

⚠️ Common Mistakes and Misconceptions

A few things trip people up when they start using a template. Let’s clear them out.

• Following the template too rigidly. Reciting “step one, step two” like a robot kills the conversation. The steps are a guide in your head, not a speech.
• Skipping steps. Jumping straight to drawing boxes and skipping requirements or estimation means you design the wrong thing. Walk the steps in order.
• Spending all your time on one step. Going deep on requirements for twenty minutes leaves no time for the design. Watch the clock and keep moving.
• Ignoring the interviewer’s hints. If they ask about one piece and you keep talking about another, you’ve stopped listening. Follow where they lead.

🛠️ Practice Challenge

Time to run the template yourself. Take a simple prompt: “Design a poll app, where a user creates a poll with options and others vote on it.”

Walk through every step on paper, in order.

• Clarify. What would you ask? How many polls? Can a user vote more than once?
• Estimate. Is this read-heavy or write-heavy? (Hint: many people view results, fewer create polls.)
• API. What endpoints? Maybe createPoll(userId, options), vote(pollId, optionId), and getResults(pollId).
• High-level design. Draw client, load balancer, app servers, database, cache. Walk the “view results” flow.
• Deep dive. Pick one piece, maybe caching results, since they’re read far more than written.
• Bottlenecks. Where would it strain if one poll went viral? What fix, and what’s the cost?
• Wrap up. Summarize, and say what you’d improve with more time.

Do this out loud, as if someone’s listening. The more you run the template on small prompts, the calmer you’ll be when a big one lands.

🧩 What You’ve Learned

You now have one reusable template for any system design question. Here’s what you’ve picked up.

• ✅ One fixed set of steps works for almost any “design X” prompt.
• ✅ The order is requirements, estimate, API, high-level design, deep dive, bottlenecks and trade-offs, wrap up.
• ✅ Keep a rough time budget so you don’t blow your minutes on one step.
• ✅ Clarify scope first, then estimate, before you ever draw a box.
• ✅ Deep dive on one or two pieces and justify every choice.
• ✅ Name your own bottlenecks, the fix, and the cost.
• ✅ Hold the steps in your head, but keep it a conversation, not a recital.

🚀 What’s Next?

You’ve got the template. Now the best way to lock it in is to run it on a real problem, end to end.

• Solving a Complete Interview Question walks the full template on a real prompt, start to finish.
• The System Design Interview Process goes deeper on the why behind each step.

Run the template a few times on small designs, and “design X” will stop feeling scary and start feeling like a checklist you can work through.