System Design Interview: The Complete Guide

A system design interview asks you to design a large software system, such as a URL shortener, a chat app or a news feed, in about 45 to 60 minutes while you talk through your thinking. There’s no single correct answer. Interviewers grade how you clarify the problem, estimate the load, choose components and explain the trade-offs.

That last part is where most candidates lose points. It’s easy to name the boxes on a diagram: load balancer, app servers, cache, database. It’s much harder to explain how those boxes behave when traffic grows, two requests arrive at once or one of them fails.

I’ve sat five or six system design interviews as a candidate. Day to day, I work as a data scientist and AI engineer, building full-stack AI applications and data-driven systems with Python, FastAPI, React and SQL. This guide is the framework I wish I’d had before my first round: what the interview is, what it tests, a step-by-step approach with a time budget, one worked example and a study plan.

What is a system design interview?

A system design interview is an open-ended conversation where you design a software system from a short prompt, like “Design Instagram” or “Design a rate limiter”. You sketch the architecture on a whiteboard or a shared online canvas, and the interviewer probes your choices as you go.

It feels very different from a coding round. In a coding interview, your solution passes the tests or it doesn’t. Here the prompt is deliberately vague, and part of the job is turning it into a problem you can actually solve in 45 minutes.

Amazon’s SDE II prep page shows how companies frame it. It tells candidates to “expect at least one question on software systems design”. It also says the interviewer will ask about your design, and that you should ask questions to complete and validate it (Amazon Jobs). In other words, the questions you ask are part of your answer.

High-level design vs low-level design

You’ll see two flavours of the round:

• High-level design (HLD): services, databases, caches, queues and how data flows between them. This is what most people mean by “system design”.
• Low-level design (LLD): classes, interfaces and object relationships inside one component, such as a parking lot or an elevator controller. It’s closer to object-oriented design.

This guide focuses on high-level design. The framework still helps in LLD rounds, because both start with requirements.

What do interviewers actually evaluate?

Interviewers evaluate the quality of your decisions, not the size of your diagram. Amazon lists six objectives for its design questions: practicality, accuracy, efficiency, reliability, optimization and scalability (Amazon Jobs). In practice, they’re watching how you get from a vague prompt to a design you can defend.

From my own rounds, these are the signals that matter most:

• Requirements first. Do you clarify what the system must do, and for how many users, before choosing tools?
• Numbers. Can you estimate traffic and storage well enough to know whether one database is enough?
• Simplicity. Do you start with a design that works, then add pieces for a reason?
• Trade-offs. Can you say what each choice costs, and when you’d pick something else?
• Failure thinking. What happens when a server dies, a request is retried or two users act at once?
• Communication. Can the interviewer follow your reasoning without guessing?

The strongest candidates explain what they’d build, why they’d build it that way and when they’d choose a different approach. That last part is easy to forget. “I’d use Cassandra” is a statement. “I’d use Cassandra because writes dominate and we can tolerate eventual consistency, but if we needed transactions across users I’d go back to Postgres” is a decision.

Moment in the interview	Weak answer	Strong answer
First two minutes	Starts drawing microservices	Asks who the users are and what the system must do
Scale	“It needs to scale”	“About 4,000 reads per second at peak, so one cache tier covers it”
Technology	Kafka, Kubernetes and a NoSQL store, unexplained	Each component tied to a requirement
Data	Ignores consistency	Says which data must be strongly consistent and which can lag
Failures	Only the happy path	Walks through a node failure and a retried request
Wrap-up	Runs out of time mid-diagram	Summarises the design, its bottlenecks and next steps

A 6-step framework for any system design question

The framework I use has six steps: clarify requirements, estimate capacity, define the API and data model, sketch a high-level design, deep-dive on the critical parts, then cover failures and trade-offs. I give each step a time budget, so the important decisions get discussed before the clock runs out.

This isn’t a rigid script. If the interviewer pulls you into a deep dive early, follow them. The budget exists to stop you spending 30 minutes on the diagram and leaving five for everything that matters.

Step 1: Clarify the requirements (5 to 10 minutes)

Turn the vague prompt into a list you can design against. Split it into three groups:

• Functional requirements: what users can do. For a URL shortener, that’s creating a short link, opening it and maybe setting an expiry.
• Non-functional requirements: how well it must work. Think latency, availability, consistency and durability.
• Out of scope: what you’ll deliberately skip. Saying this out loud saves time and shows judgement.

Useful questions to ask: How many users are there? Is it read-heavy or write-heavy? Is it global or one region? Which matters more here, consistency or availability? Do we need analytics?

Step 2: Estimate the capacity (5 to 10 minutes)

Rough numbers decide your architecture. Estimate requests per second, the read/write ratio, storage growth and bandwidth. You don’t need precision. You need the right order of magnitude.

Here’s a shortcut I use all the time. A day has 86,400 seconds, so 1 million requests a day is roughly 12 requests per second. Multiply by two or three for peak traffic. If your peak is a few hundred requests per second, a single well-indexed relational database may be enough. That’s a perfectly good answer.

Step 3: Define the API and data model

Write the two or three most important API calls, with their inputs and outputs. Then list the main entities and how they relate. This step is short, but it forces clarity. How can you design storage before you know what you’re storing and how you’ll read it back?

Step 4: Sketch the high-level design (10 to 15 minutes, with step 3)

Start with the simplest design that meets the requirements: clients, a load balancer, stateless application servers and a database. Walk one request through it from start to finish.

Then add components only where a requirement or a number from step 2 demands them. A read-heavy workload earns a cache. Slow work that shouldn’t block the user earns a queue. Static content served far from your servers earns a CDN.

Step 5: Deep-dive on the critical parts (10 to 15 minutes)

Pick the one or two areas that make or break this particular system and go deep. Typical candidates are:

• database choice and schema design
• caching strategy and invalidation
• partitioning (sharding) and hot keys
• consistency requirements
• asynchronous processing with queues

Often the interviewer chooses for you. If they don’t, pick the part with the hardest trade-off and say why you picked it.

Step 6: Cover failures, bottlenecks and trade-offs (5 to 10 minutes)

Ask what breaks first if traffic grows ten times, what happens when each component fails, and what you’d change with more time. Then summarise the design in two or three sentences. A clean wrap-up leaves the interviewer with a clear picture of your thinking.

Worked example: design a URL shortener in 45 minutes

A URL shortener is the most common warm-up question. It’s small enough to finish, yet it still has real depth: key generation, read-heavy traffic and caching. Here’s how the six steps play out in compressed form. A full walkthrough is coming as its own guide.

1. Requirements. Users create a short link for a long URL and get redirected when they open it. Links can optionally expire. Redirects must be fast and highly available. Analytics and custom domains are out of scope for this round.

2. Estimates. Assume 100 million new links a month.

• Writes: 100 million ÷ (30 × 86,400 seconds) ≈ 40 writes per second.
• Reads: assume 100 redirects per link, so about 4,000 reads per second, or 8,000 at peak.
• Storage: at about 500 bytes per record, 1.2 billion links a year is 600 GB, so roughly 3 TB over five years.

These numbers already tell a story. Writes are tiny and reads dominate, so caching will matter far more than write throughput.

3. API and data model.

• POST /urls with {long_url, expires_at} returns {short_code}.
• GET /{short_code} returns an HTTP redirect (301 or 302) to the long URL.
• One main table holds short_code (primary key), long_url, created_at and expires_at.

4. High-level design. Clients hit a load balancer, which spreads requests across stateless app servers. Writes go to the database. Reads check a cache first and fall back to the database on a miss.

5. Deep dive: generating short codes. With 62 characters (a–z, A–Z, 0–9) and seven positions, you get 62⁷, or about 3.5 trillion, possible codes. That’s plenty. The hard part is avoiding collisions across many servers.

There are two common options. You can hash the long URL and handle collisions. Or you can give each server a block of numeric IDs from a central counter and encode them in base 62. The second avoids collision checks, but it needs a reliable service to hand out the blocks.

6. Failures and trade-offs. If the cache goes down, every read hits the database, so the database needs headroom or read replicas. A viral link becomes a hot key, which a small in-memory cache on each app server can absorb. And the redirect type is a real trade-off: a 301 lets browsers cache the result and cuts your load, but you lose visibility into clicks, while a 302 sends every click through your servers.

Notice what’s missing: no Kafka, no microservices, no Kubernetes. Nothing in the requirements asked for them.

What are the most common system design interview mistakes?

The most common mistake is choosing technology before understanding the problem. Weak answers often jump straight to microservices, Kafka, Kubernetes or a distributed database without explaining why the system needs them. These are the mistakes that cost candidates the most, and what to do instead:

1. Skipping requirements and capacity estimates. Without them, every later decision is a guess. Spend the first ten minutes here.
2. Choosing tools before understanding the problem. Name the requirement first, then the component that serves it.
3. Ignoring consistency, failures and bottlenecks. A design that only works on the happy path isn’t finished.
4. Overengineering a simple system. A URL shortener with 40 writes per second doesn’t need an event-streaming platform.
5. Listing components without trade-offs. Every choice costs something. Say what it costs.
6. Drawing too much and explaining too little. The diagram supports the conversation. It isn’t the answer.

System design isn’t about drawing the most complicated architecture. It’s about understanding the requirements, identifying the constraints, explaining the trade-offs and making decisions that solve the actual problem.

How do expectations change with seniority?

The questions often stay the same across levels, but the depth expected changes. A junior candidate who produces a clear, working design is usually doing well. A senior candidate is expected to drive the conversation, spot the hard parts without prompting and reason about failures, operations and cost. Expectations vary by company and team, so ask your recruiter which level the round is calibrated for.

Level	What a good answer usually looks like
Entry level	Clear requirements, a sensible high-level design and correct basics such as indexes, caching and load balancing
Mid level	A complete design with estimates, one or two solid deep dives and sensible trade-offs
Senior and above	Drives the discussion, finds the real bottleneck early and covers failures, data integrity, operations and cost

How do Indian product companies, service companies and FAANG differ?

Interview expectations vary a lot between companies and even between teams, so treat this as a broad pattern rather than a rule. Here’s how I see the three groups.

Indian product companies tend to connect design questions to practical product problems: traffic spikes during peak events, payment reliability, inventory consistency or real-time delivery tracking. You may need to balance scale against cost, latency and business requirements rather than just maximising throughput.

Service companies can put more weight on fundamentals, requirements gathering, client constraints and integration with existing systems. You might work across several client architectures, so adaptability matters. This varies by role and account.

FAANG-style interviews are often associated with structured problem-solving, scalability, reliability and explicit trade-off analysis, particularly for senior roles. The depth expected depends on the level and the company.

My takeaway is simple. Don’t memorise company-specific answers. Strong fundamentals let you adapt to any of these formats.

Which topics should you know before the interview?

You don’t need to know every database ever built. You need a working understanding of about 15 to 20 building blocks and when each one helps. These come up again and again:

Building blocks

• Load balancing, including L4 vs L7
• Caching strategies and cache invalidation
• Content delivery networks (CDNs)
• Message queues and asynchronous processing
• API styles: REST, gRPC and GraphQL
• Real-time delivery: WebSockets, long polling and server-sent events

Data and storage

• SQL vs NoSQL, and how to choose
• Database indexing
• Replication
• Sharding (partitioning)

Distributed systems

• The CAP theorem and consistency models
• Consistent hashing
• Unique ID generation

Scale and performance

• Back-of-the-envelope estimation
• Latency numbers every engineer should know
• Rate limiting

We’re writing a dedicated guide on each of these topics, and this page will link to every one as it’s published.

Which system design interview questions come up most often?

A small set of classic questions covers most of what you’ll be asked, because each one exercises a different building block. If you can design these well, you can handle most variations:

• URL shortener: key generation and read-heavy caching
• Rate limiter: limiting algorithms and distributed counters
• Unique ID generator: ordering and uniqueness across machines
• Chat app like WhatsApp: real-time connections and message delivery
• News feed like Instagram: fan-out, ranking and caching
• Notification system: queues, retries and multiple channels
• Typeahead or autocomplete: prefix search at low latency
• Web crawler: politeness, deduplication and scale
• Video streaming like YouTube: upload pipelines and CDNs
• Ride-hailing like Uber: location updates and matching
• Ticket booking like BookMyShow: concurrency without double booking
• Payment system: idempotency and consistency

AI system design is showing up too. Exponent, an interview-prep platform, reports that LLM infrastructure questions now appear in general software engineer loops, for example designing a system that serves a large language model (Exponent). Coming from AI engineering, I expect these questions to become more common.

How should you prepare for a system design interview?

Good preparation combines three things: understanding core concepts, practising complete design problems and connecting theory to real implementations. Reading alone creates an illusion of progress. You only find your gaps when you try to design something yourself.

1. Learn the concepts. Study indexing, caching, load balancing, replication, partitioning, message queues, consistency and fault tolerance. Aim to explain each one in two minutes, including when you’d avoid it.
2. Practise full problems, alone first. Pick a classic question, set a 45-minute timer and design it on paper using the six steps. Only then compare your answer with a strong solution. The list of things you missed is your study plan.
3. Build something real. Implementation exposes details that diagrams hide: database constraints, API boundaries, concurrency issues, error handling and slow queries. A small FastAPI service with a database and a cache teaches more than another architecture diagram.
4. Do mock interviews. Explaining a design out loud is its own skill. Practise with a friend, or record yourself and listen back.

Here’s a 6-week plan that follows that order. Adjust the pace to your experience: if you build backend systems every day, you may need less time on the first two weeks.

Week	Focus
1–2	Core concepts: caching, load balancing, databases, replication, sharding and queues
3	Estimation drills, plus the 6-step framework on two easy problems
4–5	One timed problem every two days, then compare with a strong solution and note the gaps
6	Mock interviews and a second pass over weak areas

What to read

• Designing Data-Intensive Applications by Martin Kleppmann and Chris Riccomini. The second edition came out from O’Reilly in March 2026 (Martin Kleppmann). It’s the best book for understanding why systems behave the way they do, though it isn’t written as interview prep.
• System Design Interview, volumes 1 and 2, by Alex Xu. It’s useful for the interview format and for worked problems.
• The System Design Primer on GitHub. It’s a free overview with Anki flashcards and more than 370,000 stars.

What to avoid

Don’t memorise architecture diagrams without understanding their assumptions. A memorised answer falls apart the moment the interviewer changes one requirement, and good interviewers always change one.

What production work teaches you about system design

Working on backend and data-driven applications made me pay much more attention to correctness and operational details, not just the happy path. Those details are exactly what interviewers probe in the deep-dive and failure sections.

Here’s what I mean:

• Concurrency: a booking system has to handle simultaneous requests without assigning the same seat twice.
• Retries and duplicates: a data pipeline has to cope with retries, duplicate processing and failures between stages.
• Growth: a database-backed application needs the right transaction boundaries and indexes as its workload grows.

A design isn’t complete just because requests flow through its components. It has to behave correctly under concurrency, recover from failures and stay maintainable as requirements change. Bring that mindset into the interview, and your answers will sound like they come from someone who has shipped real software.

Frequently asked questions

How long is a system design interview?

Most system design rounds last 45 to 60 minutes. Some companies also test design elsewhere in the process: Amazon’s SDE II online assessment includes 20 minutes of systems design scenarios (Amazon Jobs). Budget your time so you reach the deep dive and the failure discussion.

Do freshers get system design interviews?

Sometimes, though usually a lighter version. Entry-level rounds tend to focus on fundamentals or on low-level, object-oriented design rather than large distributed systems. It depends on the company, so check with your recruiter. Learning the basics early still pays off, because the same concepts come back in later rounds.

Do you need to write code in a system design interview?

Usually not. You’ll describe components, APIs and data models, and you might sketch an API signature or a table schema. Low-level design rounds are the exception, since they can involve class definitions and interfaces.

How long does it take to prepare?

If you already work on backend systems, four to six weeks of steady practice is a realistic target. If replication and sharding are new to you, plan for longer. Regular timed practice matters more than total hours.

What if the interviewer mentions a technology I don’t know?

Say so, then reason from principles. “I haven’t used Cassandra in production, but if it’s a wide-column store optimised for writes, here’s how I’d model the data” is a strong answer. Bluffing is easy to spot and costs more than honesty.

Is there one right answer?

No. Different candidates reach different designs, and interviewers expect that. They’re checking whether your design meets the requirements you agreed on and whether you can defend its trade-offs.

Start with the framework

A system design interview rewards clear thinking more than encyclopaedic knowledge. Clarify the requirements, estimate the scale, start simple, go deep where it matters and finish with failures and trade-offs.

Pick one classic question this week, set a 45-minute timer and run the six steps on paper. Then read a strong solution and list what you missed. Repeat that loop a dozen times, and the interview will start to feel like a conversation instead of an exam.

Is there a question you’d like explained next? Send it through our contact page, and it may become the next guide.