The mistake candidates make first
Most candidates lose this round in the first five minutes, before they've drawn a single box. They hear “design Instagram” and start naming services — feed, media storage, notifications — without asking what the interviewer is actually grading them on.
This guide is System Design in a Hurry. It works backwards from the interview: not every database ever built, but what a strong candidate actually does in 45 minutes when someone says Design Instagram.
That backwards approach matters for two reasons:
- If you're short on time before your interview, you learn the highest-impact ideas first.
- You connect each concept to a real system and a real failure mode — not academic knowledge you'll never use in the room.
Most system design material fails in one of two directions: too shallow to survive a follow-up question, or too deep to fit in an hour. Going too deep in the room is its own problem — interviewers read it as a yellow flag, not a flex. This guide aims for dense and practical instead.
What are system design interviews?
System design interviews test your ability to take an ambiguously defined, high-level problem and break it into the infrastructure pieces needed to solve it.
They're practical interviews, not academic ones. Most engineers find them closer to real work than a LeetCode round.
There's no single right answer. Most prompts have several valid designs. Your interviewer is grading how you navigate complexity, reason about trade-offs, and communicate — not whether you recite one memorized diagram.
Who actually faces these interviews?
- Entry-level — usually no system design round. Plenty of exceptions.
- Mid-level — common now. Basics are expected; depth is a bonus.
- Senior — the norm, and it carries disproportionate weight in your final rating.
- Staff+ — a different bar entirely: org-level trade-offs, not boxes and arrows.
Types of system design interviews
Every company — sometimes every interviewer — runs this loop a little differently. Almost all of it falls into two buckets, and this guide covers both:
- Product design — the system behind a user-facing product. Example: design the booking flow for a ride-sharing app like Uber, or the feed for a food delivery app like Swiggy.
- Infrastructure design — the plumbing itself. Example: design a rate limiter, or design how a ticketing backend survives ten lakh concurrent logins the moment booking opens.
Both need real infra — services, load balancers, databases, caches, queues. If that's your interview, you're in the right place.
Not the right spot?
“System design” is an umbrella term. If your loop looks different, you want another track:
- Low-level design (LLD / OOP) — class structure and object relationships. One component in detail, not the whole system.
- ML system design — feature pipelines, training, serving. The model lifecycle, not the request path.
- Frontend system design — rendering, state management, client performance at scale.
Assessment — how you're scored
Interviewers score you across the whole hour, not just the final diagram. Every company's rubric reads a little differently, but the themes repeat.
Baseline expectation: everyone delivers a working design that satisfies the requirements. A mid-level engineer covers the basics solidly but may not go deep. A senior engineer moves through the basics fast and spends the saved time on a deep dive that actually shows experience.
Regardless of level, rubrics touch the same four themes (the wording varies):
- Problem navigation — explore, prioritize, stay unstuck.
- Solution design — sensible architecture for the constraints.
- Technical excellence — know building blocks and apply them well.
- Communication & collaboration — think with the interviewer, not against them.
Problem navigation
Problem navigation is often the most important competency — and where most candidates, especially those new to system design, slip hardest.
It means taking a complex, under-specified problem, breaking it into manageable pieces, prioritizing the important ones, and navigating to a working solution. Fail here and you'll burn time solving the wrong problems while leaving a poor impression.
If the prompt is “design Twitter” and you spend the first ten minutes drawing a six-column User table before asking whether this is about tweets, DMs, or the timeline — you looked busy. You didn't scope the problem.
Most common failure modes:
- Insufficiently exploring the problem and gathering requirements.
- Focusing on uninteresting or trivial aspects instead of what actually matters.
- Getting stuck on one piece and not being able to move forward.
- Failing to deliver a working system — lots of boxes, no coherent end-to-end path.
Solution design
You're not graded on the perfect architecture — you're graded on how clearly you reason toward one.
With the problem broken down, your interviewer wants to see how you solve each piece — and how those pieces fit into a cohesive whole. This is where your Core Concepts knowledge pays off.
Spend your depth budget on the riskiest part of the design — fan-out, payments, search — not on decorative microservices nobody asked about. Senior candidates are recognizable by where they choose to go deep, not by how many boxes they draw.
Most common failure modes:
- Not understanding core concepts deeply enough to solve the actual problem.
- Ignoring scaling and performance considerations.
- "Spaghetti design" — a solution that's hard to follow and doesn't hang together.
Technical excellence
To design a great system, you need best practices, current technologies, and the judgment to apply them. This is your Key Technologies knowledge — Redis, Kafka, load balancers, sharding patterns, and when each actually earns its place.
Technical excellence means knowing what actually happens when Redis evicts your hot keys, when a shard goes down, or when queue lag spikes because fifty million people just started watching the same six-ball over. Naming the tool isn't the skill — explaining the failure mode is.
Most common failure modes:
- Not knowing about available technologies.
- Using antiquated approaches or outdated hardware assumptions.
- Not knowing how to apply technologies to the problem at hand.
- Missing common patterns and best practices.
Hardware hasn't stood still in a decade — but much system design material is still stuck in 2015. Throughout this guide we call out where old advice no longer applies, and share numbers to know that help you make better decisions under time pressure.
Communication & collaboration
Technical interviews also answer: what would it be like to work with you? System design rounds are frequently collaborative. Your interviewer wants to see how you communicate complex ideas, respond to feedback, and solve problems together.
Most common failure modes:
- Not communicating complex concepts clearly.
- Being defensive or argumentative when receiving feedback.
- Getting lost in the weeds and losing the collaborative thread.
How to use this guide
We recommend reading this path in order, skipping sections you already know well. Start with How to approach a design question for a structure to organize your preparation.
- Read Start here top to bottom if time is short.
- Follow Foundations and Technologies roadmaps — skim maps, open deep dives where you're weak.
- After each article, close the tab and redraw the diagram from memory.
- Apply in Common patterns, then Question breakdowns.
We've tried to make this guide as self-contained as possible. Don't worry if you don't have time for every external reference — the essentials are here.
This path includes worked solutions to common problems. Along the way, test yourself: close the article, set a timer, and walk through the design as if the interviewer were in the room.
The full learning path
Read in sidebar order. Each phase answers one question before the next makes sense.
- Start here — How you're graded, how to prepare, delivery framework, pitfalls.
- Foundations — Numbers → Concepts roadmap → networking → API → data → indexing → proximity → scale → sharding → CAP → consistency → probabilistic structures (optional).
- Technologies — Tech roadmap → databases → cache → queues → processing → search → edge → infra.
- Common patterns — Reusable recipes (realtime, async, contention, scale reads/writes).
- Question breakdowns — Full walkthroughs with trade-offs spelled out loud.
How much time do you need?
- System design entirely new to you → plan 3–4 weeks of focused prep, or an intense dedicated sprint.
- Already familiar with core concepts or have production experience → many candidates prepare successfully in under a week.
- Either way → skim In a hurry first to see what's ahead.
Really short on time? Follow the curriculum in order — these four checkpoints cover most interviews:
- How to approach a design question — delivery framework.
- Core concepts roadmap — skim defaults, open articles only where you're weak.
- Key technologies — one tool per layer.
- Two question breakdowns end-to-end.
Cost and performance levers
Interview Q&A by level
Practice saying these out loud for system design interviews. Interviewers grade clarity and judgment more than buzzwords.
Match depth to the bar: define → trade off → operate. Don't dump principal answers in an entry-level screen.
Conclusion
System design interviews reward engineers who can think in public under ambiguity — not the ones who memorized the most AWS service names.
Read How to prepare next for a two-phase plan, then How to approach a design question for the delivery framework itself.
How this curriculum maps to a 45-minute interview
What "good" looks like
Interviewers remember candidates who: (1) ask crisp clarifying questions, (2) estimate before drawing, (3) pick boring reliable defaults, (4) deep-dive one real bottleneck, (5) narrate trade-offs without freezing.
Failure modes to mention
Call out at least one dependency failure (DB down, cache stampede, queue lag, region outage) and your mitigation (timeouts, retries with jitter, degraded mode, circuit breaker).