DEV Community: Arslan Ahmad

The 2027 System Design Interview Playbook: Framework, Concepts, and a Full Worked Example

Arslan Ahmad — Mon, 02 Nov 2026 13:38:14 +0000

A quick note before we start: This guide is written by me, Arslan Ahmad. I'm the founder of DesignGurus.io and the author of Grokking the System Design Interview. Before that, I spent years as a software engineer and hiring manager at Microsoft and Meta, where I sat on the other side of hundreds of these interviews. Where one of our courses or articles goes deeper on a topic, I link it. You can follow everything in this playbook without buying anything.

If you're preparing for a system design interview in 2027, you're facing a strange situation. There's more free material than ever, and it has never been harder to know what to study.

Most guides give you one of three things: a list of concepts with no idea how to use them, a framework with no worked example, or a single example with no reusable method. Candidates come out of those guides knowing what a load balancer is but freezing when an interviewer says "Design Instagram's feed. You have 45 minutes."

This playbook gives you all three in one place:

A framework you can apply to any question, with a minute-by-minute time budget.
The core concepts that show up in nearly every interview, explained at the depth interviewers actually probe.
A full worked example (a news feed), done the way I'd want a strong senior candidate to do it, with real numbers, a data model, deep dives, and failure handling.

It's long on purpose. Bookmark it, skim the table of contents, and come back to the sections you need.

TL;DR: The 60-Second Version

The interview tests how you think, not what you've memorized. There's no single correct answer. There are defensible trade-offs.
Use a framework every time: clarify requirements → estimate scale → define the API → model the data → high-level design → deep dives → bottlenecks and wrap-up.
Spend the first ~15 minutes on scope, numbers, API, and data. Candidates who skip this end up designing the wrong system very well.
Know ~15 building blocks cold: load balancers, caches, CDNs, SQL vs NoSQL, replication, sharding, consistent hashing, queues, rate limiting, idempotency, IDs, CAP/PACELC, consistency models, observability, API styles.
Every decision should come with a "because." "I'll use Cassandra because the workload is write-heavy, access is by key, and we can tolerate eventual consistency."
Seniority is judged by how you drive the conversation, not by how many boxes you draw.
2027 additions: expect AI/LLM system questions, more focus on cost and observability, and designing APIs that AI agents (not just humans) will call.

What Is a System Design Interview?
What's Different About System Design Interviews in 2027
The Types of System Design Interviews
How You're Evaluated (and What Changes by Level)
The 7-Step System Design Interview Framework
Core Concepts: The System Design Toolkit
The Trade-offs Interviewers Love to Probe
Full Worked Example: Design a News Feed
Bonus: A Template for AI System Design Questions
The Most Common System Design Interview Questions
12 Mistakes That Sink Strong Candidates
An 8-Week Preparation Plan
Best Resources to Prepare
FAQ

What Is a System Design Interview?

A system design interview is a 45 to 60 minute conversation where you design a large-scale software system from a vague prompt. "Design a URL shortener." "Design WhatsApp." "Design a rate limiter." "Design a system that lets 10 million people buy concert tickets at the same moment."

You'll usually work on a whiteboard or a shared online diagramming tool. The interviewer plays a mix of product manager, tech lead, and skeptical colleague. They answer your questions, push on weak spots, and steer you toward the parts they want to see in depth.

What it is not:

Not a trivia quiz. Nobody will ask you to recite the Raft paper. They'll ask you why you need consensus here and what happens if the leader dies.
Not a test of whether you've built this exact system. Very few candidates have built Twitter. Interviewers know that.
Not a search for the "right" architecture. Two candidates can draw very different diagrams and both get a strong hire. What matters is whether your choices fit the requirements and whether you can defend them.

What it is: a simulation of a design review. The question behind every question is, "Would I trust this person to lead the design of a real system on my team?"

That's why the system design round carries so much weight in leveling decisions. A coding round tells a company whether you can write correct code. A system design round tells them whether you're a mid-level, senior, or staff engineer. If you want the long version of how this round fits into the loop, I wrote about it in System Design Interview Fundamentals.

What's Different About System Design Interviews in 2027

The core of the interview hasn't changed in a decade: requirements, scale, components, trade-offs. But the questions and the bar around them have shifted. Here's what I'm seeing from candidates and hiring managers going into 2027.

1. AI system design questions are now mainstream. "Design ChatGPT," "Design a RAG-based support bot," and "Design an LLM inference service" have moved from niche ML loops into general backend loops. You don't need to be an ML researcher, but you do need to know how retrieval, vector search, model serving, token streaming, and GPU cost fit into an architecture. I added a template for these below.

2. Your API's clients might be agents, not people. More systems now have AI agents calling them in tight loops. That raises the stakes on things that used to be "nice to have": idempotency keys, strict rate limits per key, machine-readable errors, pagination that doesn't break under retries, and clear contracts.

3. Cost is a first-class requirement. Interviewers increasingly ask, "What does this cost to run?" A design that needs 4,000 GPUs or petabytes of hot Redis isn't automatically wrong, but you should notice and say so.

4. Observability and failure modes get more airtime. "How would you know it's broken?" and "What happens when the cache cluster dies?" are now standard follow-ups, especially at senior levels.

5. Interviewers expect you to drive. With so much prep material available, the baseline has gone up. Reciting a memorized "Design Twitter" answer stands out less than it used to. Adapting your design to the interviewer's twist stands out more.

6. Some companies now allow AI tools in parts of the loop. Policies vary a lot between companies and change often, so ask your recruiter. Even where AI assistance is allowed, the system design round is still mostly about your judgment: what to build, what to skip, and why.

None of this changes the fundamentals. If anything, it rewards them more. You can't reason about LLM serving costs if you can't do back-of-the-envelope math.

The Types of System Design Interviews

"System design" covers a few different interview formats. Find out which one you're getting, because the prep is different.

Type	Typical prompt	What they're really testing
Product / backend design	Design Instagram, Uber, Dropbox	End-to-end architecture, data modeling, scaling
Infrastructure design	Design a rate limiter, key-value store, message queue	Distributed systems depth, consistency, failure handling
API design	Design the API for a payments platform	Resource modeling, versioning, idempotency, pagination
Object-oriented / low-level design	Design a parking lot, elevator system	Classes, interfaces, design patterns, extensibility
AI / ML system design	Design ChatGPT, a recommendation system	Data pipelines, model serving, evaluation, cost
Mobile / frontend system design	Design the Instagram mobile app	Client architecture, offline sync, caching, rendering

Most backend and full-stack engineers will see product design and infrastructure design. Meta, for example, has long split its loop into "product architecture" and "system design" flavors. I break down each format in Types of System Design Interviews: Product, Infrastructure, and More.

This playbook focuses on the product and infrastructure formats, because that's where most people need help. The framework applies to all of them.

How You're Evaluated (and What Changes by Level)

Interviewers don't score your diagram. They score signals. Almost every big-tech rubric I've seen boils down to four:

Problem navigation. Do you scope the problem before solving it? Do you ask questions that change the design, not questions for the sake of asking?
Solution design. Do the components fit together into something that would actually work end to end?
Technical depth. When pushed on a component, do you know why it works, not just what it is?
Communication. Do you think out loud, check in, and adjust when the interviewer gives you a hint?

The same question is asked to mid-level, senior, and staff candidates. What changes is the bar.

L4 / mid-level: You can produce a working design with reasonable components. The interviewer may guide you through some steps. You discuss a couple of trade-offs.
L5 / senior: You drive the whole conversation without prompting. You pick the two or three hardest parts of the problem and go deep. You back decisions with numbers and plan for failure.
L6 / staff: You reframe the problem. You compare multiple architectures before committing. You talk about cost, migration paths, operational burden, and what you'd deliberately not build in v1.

Here's a practical way to tell where you are: record yourself doing a mock interview, then count how many times the interviewer had to redirect you. Senior candidates rarely need it. I wrote about the specific behaviors that separate candidates in 7 Tips to Stand Out in Your System Design Interview, and I list level-appropriate practice questions in System Design Interview Questions by Level.

If you have never run a timed mock before, this guide to system design mock interviews breaks down what happens minute by minute, how the scorecard works, and which platforms to practice on.

The 7-Step System Design Interview Framework

This is the framework I've taught for years in Grokking the System Design Interview. It's not magic. It just makes sure you never skip the steps that interviewers grade, and it keeps you from panicking when the prompt is vague.

For another end-to-end walkthrough of this framework, with the exact signals interviewers score, see The Complete System Design Interview Guide for 2027.

If you prefer video, here's my walkthrough of the same 7-step method:

Let's go through each step: what to do, what to say, and what to avoid.

Step 1: Clarify Requirements (≈5 minutes)

Every system design prompt is underspecified on purpose. The interviewer wants to see whether you'll charge ahead or figure out what you're building first.

Split requirements into two lists and write both on the board.

Functional requirements are what the system does. Aim for 3 to 5 core features, and explicitly park the rest.

"For a news feed, I'm thinking the core features are: users can create posts with text and images, follow other users, and see a feed of posts from people they follow. I'll leave out comments, likes, ads, and search for now unless you'd like me to include them. Does that work?"

Non-functional requirements are how well it does it. These drive the architecture far more than the features do. Ask about:

Scale: How many users? Daily active users? Read-heavy or write-heavy?
Latency: What's acceptable for the critical path? (For a feed: p99 under ~200 ms.)
Availability vs consistency: Is it OK if a post takes a few seconds to appear for followers? (Usually yes.) Is it OK if a payment is double-charged? (Never.)
Durability: Can we ever lose data? (Posts: no. View counts: maybe.)
Other constraints: Global or single region? Mobile clients with bad networks? Compliance needs?

Avoid: asking 15 questions in a row. Ask the ones whose answers change the design, propose sensible defaults for the rest, and move on.

Step 2: Back-of-the-Envelope Estimation (≈3–5 minutes)

Estimation turns "it should scale" into "we need roughly this much." Its job is to tell you which parts of the system are hard. A design serving 100 QPS and a design serving 1 million QPS look very different.

Estimate four things:

Traffic: reads and writes per second, average and peak.
Storage: per day, per year, and total.
Bandwidth: bytes in and out per second, mostly relevant for media.
Memory: what you'd need to cache the hot set.

The trick is to round aggressively. A day has 86,400 seconds; call it 100,000 (10⁵). So 1 million requests/day ≈ 10 per second, and 1 billion/day ≈ 10,000 per second. Interviewers want the order of magnitude and your reasoning, not decimals.

Avoid: spending 10 minutes on math the design doesn't use. Every number you compute should lead to a decision ("~35K peak read QPS, so we need a cache in front of the database").

For a step-by-step method with practice problems, read Back-of-the-Envelope Estimation for System Design Interviews.

Step 3: Define the API (≈3–5 minutes)

The API is the contract between your system and the world. Writing it down forces you and the interviewer to agree on exactly what the system does.

Keep it to the 3 to 5 endpoints that match your functional requirements:

POST /v1/posts              { text, media_ids[], idempotency_key }  -> 201 { post_id }
GET  /v1/feed?cursor=&limit=20                                       -> 200 { items[], next_cursor }
POST /v1/users/{id}/follow                                           -> 204

Things worth mentioning briefly, because they show maturity:

Pagination: cursor-based, not offset-based, for anything that changes in real time.
Idempotency keys on writes, so a retried request doesn't create a duplicate.
Auth and rate limiting at the gateway.
API style: REST is the default for public APIs, gRPC is common between internal services, and GraphQL fits client-driven aggregation.

Step 4: Model the Data (≈3–5 minutes)

List the core entities, their key fields, and, most importantly, the access patterns. Your database choice should follow from how data is read and written, not from what's fashionable.

Questions to answer:

What are the main entities and relationships?
What are the top 2–3 queries? (e.g., "get the latest 20 posts for user X's feed")
Do we need transactions across entities, or mostly single-key reads and writes?
How will this be partitioned once it no longer fits on one machine?

A good habit: say out loud which database you'd pick and why, in one sentence. "Follows are a simple many-to-many relationship queried by user ID in both directions. A sharded relational store with two tables, one keyed by follower and one by followee, handles that well."

Step 5: High-Level Design (≈8–10 minutes)

Now draw the boxes. Start with the simplest design that satisfies the functional requirements end to end, then evolve it to meet the non-functional ones.

A reliable approach:

Draw the client, the entry point (load balancer / API gateway), and the services that handle each API.
Add the data stores from Step 4.
Walk through one write request and one read request end to end, out loud.
Add caches, queues, CDNs, and replicas only where your numbers from Step 2 say you need them.

Avoid: drawing 25 boxes before explaining any of them. Five well-explained boxes beat twenty-five vague ones.

Step 6: Deep Dives (≈10–12 minutes)

This is where most hiring decisions are made. Pick the two or three components that are hardest for this specific problem and go deep. Often the interviewer will steer you; at senior levels, they want to see you pick.

How to find the hard parts:

Where does the scale from Step 2 concentrate? (A hot key? A huge fan-out?)
Where do consistency requirements bite? (Payments, inventory, bookings.)
What's unique to this problem? (Geospatial search for Uber, fan-out for feeds, contention for ticketing.)

For each deep dive, present two or three options, compare them, then commit. That pattern alone separates many senior candidates from mid-level ones.

Step 7: Bottlenecks, Failures, and Wrap-up (≈5 minutes)

Finish by stress-testing your own design:

Single points of failure: what happens if each box dies?
Bottlenecks: which component saturates first as traffic grows 10×?
Hot spots: celebrity users, viral content, popular keys.
Observability: what would you monitor and alert on?
What's next: what would you add with more time?

That last image captures the key point: a system is only as fast as its slowest stage. Scaling your app servers from 8,000 to 80,000 RPS does nothing if the database tops out at 2,000.

Want the full step-by-step breakdown with examples for each step? See System Design Interview Guide – 7 Steps to Ace It.

Core Concepts: The System Design Toolkit

You don't need to know everything about distributed systems. You need a toolkit of roughly 15 concepts that you understand well enough to (a) know when to use each one and (b) answer two levels of "why?" about it.

Here's how they fit together in a typical web system:

1. Scalability: Vertical vs Horizontal

Vertical scaling (scale up) means a bigger machine. It's simple and there are no distributed-system headaches, but there's a ceiling and a single point of failure.

Horizontal scaling (scale out) means more machines. There's effectively no ceiling, but now you need load balancing, data partitioning, and a plan for partial failure.

The interview move: keep your application servers stateless (sessions in a shared store like Redis, files in object storage) so you can scale them horizontally behind a load balancer. Then focus your energy on the stateful parts, which are almost always the hard parts.

2. Load Balancing

A load balancer spreads requests across servers and routes around unhealthy ones.

L4 (transport layer) balances TCP/UDP connections. It's fast and doesn't look at content.
L7 (application layer) looks at HTTP paths, headers, and cookies, so it can route /api/video differently from /api/chat.
Algorithms: round robin, least connections, weighted, and consistent hashing (when you want the same user or key to hit the same server, e.g., for local caches).

Mention health checks, and that the load balancer itself must be redundant (active-passive pairs or a managed cloud LB), or it becomes your single point of failure.

3. Caching

Caching is the highest-leverage tool in system design. Reading from memory is roughly 1,000× faster than a disk-backed database query. A good cache can absorb 90%+ of read traffic.

Know where caches live (client, CDN, application-level like Redis, database buffer cache) and the main write policies:

Cache-aside (lazy loading): the default. App checks cache, falls back to DB on a miss, then populates the cache.
Write-through: writes go through the cache to the DB, so the cache is never stale for written keys.
Write-back: writes go only to the cache and are flushed later. Fastest, but you can lose data.

Then be ready for the follow-ups: How do you invalidate? (TTL plus explicit delete on write.) What's the eviction policy? (Usually LRU.) What happens when a hot key expires and 10,000 requests hit the database at once? (A cache stampede; fix it with request coalescing, jittered TTLs, or proactive refresh.)

Redis comes up in almost every interview, so know its data structures, not just "key → value." Sorted sets (leaderboards, feeds), hashes (objects), and streams (event logs) solve a lot of design problems on their own.

4. Content Delivery Networks (CDNs)

A CDN caches static content (images, video, JS, CSS) at edge locations close to users. It cuts latency for global users and offloads huge amounts of bandwidth from your origin.

Use a CDN for anything large and read-heavy: profile pictures, video segments, thumbnails. Mention cache keys and versioned URLs (e.g., avatar_v3.jpg) so updates don't serve stale content. A cross-continent round trip is ~150 ms, while a CDN edge is often a few milliseconds away.

5. Databases: SQL vs NoSQL

This is one of the most-asked trade-offs. Don't answer with "NoSQL scales better." Answer with access patterns.

	Relational (PostgreSQL, MySQL)	NoSQL (Cassandra, DynamoDB, MongoDB)
Schema	Fixed, enforced	Flexible
Transactions	Full ACID across rows and tables	Usually single-item or limited
Queries	Joins, ad-hoc queries	Optimized for known access patterns
Scaling writes	Harder; needs manual sharding	Built-in partitioning
Best for	Payments, orders, inventory, anything relational	High-volume key-based access, time series, feeds

A strong answer sounds like: "Orders need multi-row transactions and strong consistency, so PostgreSQL. The activity log is append-heavy, read by user ID and time range, and can be eventually consistent, so Cassandra."

Also know the specialized stores: object storage (S3) for blobs, search indexes (Elasticsearch/OpenSearch) for full-text search, time-series databases for metrics, graph databases for deep relationship queries, and vector databases for embeddings in AI systems.

For the deeper comparison, see SQL vs. NoSQL: Key Differences.

6. Indexing

An index makes reads fast at the cost of slower writes and extra storage. B-tree indexes handle range queries; hash indexes handle exact matches. LSM-tree storage engines (Cassandra, RocksDB) make writes cheap by appending and compacting later.

The interview-relevant point: design your indexes around your queries. If your top query is "posts by user, newest first," you want a composite index (or a partition + clustering key) on (author_id, created_at DESC).

7. Replication

Replication keeps copies of data on multiple machines for availability, durability, and read scaling.

Leader–follower (primary–replica): one node takes writes, replicas serve reads. Simple, but replicas can lag (stale reads), and failover needs care.
Multi-leader: multiple nodes accept writes (e.g., one per region). Good for geo-distribution, but you have to resolve write conflicts.
Leaderless (Dynamo-style): any replica accepts writes; reads and writes use quorums (e.g., with N=3, W=2, R=2, so R + W > N guarantees overlap).

Know synchronous vs asynchronous replication: synchronous is safer but slower; asynchronous is faster but can lose the latest writes on failover.

8. Sharding (Partitioning) and Consistent Hashing

When data or write traffic outgrows one machine, you split it across many. The hard part is picking the shard key.

Range-based: easy range scans, but risk of hot spots (all new data hits the last shard).
Hash-based: even distribution, but range queries become scatter-gather.
Directory-based: a lookup service maps keys to shards. Flexible, but it's another component to keep available.

Consistent hashing solves the "add a server and everything moves" problem. With hash(key) % N, going from 4 to 5 servers remaps about 80% of keys. On a hash ring, only about 1/N of keys move. Virtual nodes smooth out the distribution further. This shows up in caches, Dynamo-style databases, and load balancers. If you want a dedicated walkthrough, I wrote How to Use Consistent Hashing in a System Design Interview.

Always mention hot keys: a celebrity's user ID or a viral post can overload one shard no matter how good your hash function is.

9. CAP and PACELC

CAP: when a network partition happens, a distributed system must choose between consistency (every read sees the latest write, or gets an error) and availability (every request gets a response, possibly stale). You can't skip partitions in a real network, so "CA" isn't a real option for a distributed system.

PACELC extends this: if there's a Partition, choose Availability or Consistency; else (normal operation), choose Latency or Consistency. This is the more useful framing, because your system spends most of its time not partitioned.

The senior move is to choose per feature, not per system. A social app's feed can be AP/EL; the payments for promoted posts in the same app must be CP/EC.

10. Consistency Models

Between "strong" and "eventual" there's a useful middle ground, and naming it precisely is a strong signal:

Strong (linearizable): every read sees the latest write. Expensive, especially across regions.
Eventual: replicas converge if writes stop. Cheap and highly available.
Read-your-writes: a user always sees their own updates (e.g., your own post shows up in your feed immediately), even if others see it a moment later.
Monotonic reads: a user never sees data go "back in time" between requests.
Causal: if A caused B (a reply to a comment), everyone sees A before B.

Read-your-writes is the one that saves you in most product designs. Users tolerate others being a few seconds behind; they don't tolerate their own action disappearing. More on this in Consistency Patterns in Distributed Systems.

11. Message Queues and Event-Driven Architecture

Queues decouple producers from consumers. A service publishes an event, and any number of consumers process it at their own pace.

Why they matter in interviews:

Absorb spikes: the queue buffers bursts that would otherwise overwhelm downstream services.
Async work: send emails, resize images, update search indexes without blocking the user's request.
Fan-out: one "OrderPlaced" event feeds inventory, fulfillment, notifications, analytics, and fraud, as in the diagram above.

Know the difference between a queue (SQS, RabbitMQ: each message is processed by one consumer, then deleted) and a log/stream (Kafka, Kinesis: messages are retained and can be replayed by many consumer groups). Know delivery semantics: at-most-once, at-least-once (the common default), and "effectively once" via idempotent consumers. And know back pressure: what happens when consumers can't keep up.

12. Rate Limiting

Rate limiting protects your system from abuse, runaway clients, and (increasingly) runaway AI agents. Common algorithms:

Token bucket: allows bursts up to the bucket size, then a steady rate. The most common choice.
Leaky bucket: smooths output to a constant rate.
Fixed window counter: simple, but allows bursts at window edges.
Sliding window log/counter: more accurate, a bit more expensive.

In a distributed setup, counters usually live in Redis with atomic operations (or a Lua script). Rate limiting is also a classic standalone interview question; I walk through it in How to Design a Rate Limiter (Step by Step).

13. Idempotency and Retries

Networks fail, clients retry, and at-least-once queues redeliver. Any operation that can be retried must be safe to repeat.

Have clients send an idempotency key with each write; the server stores the key and the result, and returns the stored result for repeats.
Make consumers idempotent (e.g., "set status to SHIPPED" instead of "increment shipped count").
Use exponential backoff with jitter on retries, so a recovering service isn't flattened by a synchronized retry storm.

In any design involving money, orders, or bookings, bring this up before the interviewer does.

14. Unique ID Generation

Auto-increment IDs don't work across shards. Common options:

UUIDv4: no coordination, but 128 bits, random, and not sortable (bad for B-tree index locality).
UUIDv7 / ULID: time-ordered, sortable, and no coordination needed.
Snowflake-style IDs: 64-bit = timestamp + machine ID + sequence. Compact and roughly time-sorted, which makes them perfect as cursors for feeds.

15. Observability and Reliability

You can't operate what you can't see. Mention:

Metrics: the four golden signals (latency, traffic, errors, saturation), plus business metrics.
Logs and distributed tracing: to follow one request across many services.
SLOs: e.g., "99.9% of feed requests under 200 ms." Error budgets tell you when to slow down releases.
Resilience patterns: timeouts, retries with backoff, circuit breakers, bulkheads, graceful degradation (serve a stale feed rather than an error page).

There are 60+ named patterns in this space. I collected them, with when to use each, in System Design Patterns: The Complete Guide. For a one-page version of this whole toolkit, there's also the System Design Cheat Sheet.

Where to learn these properly: If several of these concepts are new to you, start with Grokking System Design Fundamentals. It covers each building block from scratch. If you know the basics but struggle to apply them under pressure (when to shard, what to cache, how to survive failures), Grokking Scalable Systems for Interviews treats caching, sharding, replication, and fault tolerance as design decisions rather than definitions.

The Trade-offs Interviewers Love to Probe

System design is the art of choosing what to give up. Here are the trade-offs that come up most often, with a one-line rule of thumb for each.

Trade-off	Lean toward the first when…	Lean toward the second when…
Consistency vs availability	Money, inventory, bookings	Feeds, likes, view counts
Latency vs throughput	User-facing requests	Batch jobs, analytics
SQL vs NoSQL	Relationships, transactions	Massive scale, simple key access
Push vs pull	Readers far outnumber writers	Writers with huge audiences
Sync vs async	The user needs the result now	The work can happen later
Cache-aside vs write-through	Read-heavy, staleness OK	Must read your own writes from cache
Monolith vs microservices	Small team, early product	Many teams, independent scaling
Strong vs eventual consistency	Correctness is critical	Scale and latency matter more
Batch vs stream processing	Daily reports, ML training	Fraud detection, live dashboards
Normalize vs denormalize	Write-heavy, integrity matters	Read-heavy, joins are too slow

The phrase that signals seniority: "It depends on X. Given our requirement of Y, I'd choose Z, and the cost is W." For a deeper treatment of how to reason through these in the room, see System Design Trade-Offs: How to Navigate Them Like a Senior Engineer.

Full Worked Example: Design a News Feed

Let's put everything together. I'll walk through "Design a news feed" (think Instagram, Facebook, or X/Twitter home timeline) exactly as I'd want a strong senior candidate to do it in 45 minutes. I'll also mark where an L4, L5, and L6 answer would differ.

I picked the news feed because it touches almost every concept above: caching, sharding, queues, fan-out, hot keys, consistency, and ranking. If you can do this one well, you can adapt it to Twitter timelines, notification systems, activity feeds, and more.

Step 1: Requirements

Functional (in scope):

Users can create posts (text + optional images/video).
Users can follow/unfollow other users.
Users see a home feed of posts from people they follow, newest first (with light ranking later).
Feed supports infinite scroll.

Out of scope (said out loud): comments, likes, ads, search, stories, DMs.

Non-functional:

Scale: 500M monthly users, 200M daily active users.
Latency: feed load p99 < 200 ms.
Availability: high (99.99%). A slightly stale feed is better than an error.
Consistency: eventual is fine for followers (a few seconds of delay is OK), but authors must see their own posts immediately (read-your-writes).
Durability: posts must never be lost.
Read-heavy: reads far outnumber writes.

Step 2: Estimation

Assumptions (state them, then compute):

200M DAU, each opens the feed 5 times/day → 1B feed reads/day.
10% of DAU post once a day → 20M new posts/day.
Average user has ~200 followers; a small number of accounts have millions.
Post metadata ≈ 1 KB; 20% of posts include media averaging ~500 KB.

Traffic:

Feed reads: 1B / 10⁵ s ≈ ~12K QPS average, ~35K QPS peak (3×).
Post writes: 20M / 10⁵ ≈ ~230 QPS average, ~700 QPS peak.
If we fan out on write: 20M posts × 200 followers = 4B feed inserts/day ≈ 46K/s average. This is the number that should make you pause.

Storage:

Post metadata: 20M × 1 KB = 20 GB/day ≈ 7 TB/year. Easy.
Media: 4M × 500 KB = 2 TB/day ≈ 730 TB/year → object storage + CDN, not the database.

Feed cache size:

Keep the latest 500 post IDs per active user. Each entry ≈ 16 bytes (8-byte ID + 8-byte score) → 8 KB/user.
200M users × 8 KB = 1.6 TB raw, maybe 5–8 TB with Redis overhead. That's a large but very normal Redis cluster (dozens of nodes). Capping at 200 entries would cut it by more than half.

What the numbers tell us: reads dominate, so precomputing feeds is worth it. But the fan-out write volume is large and spiky, so it has to be asynchronous, and celebrity accounts need special handling.

L4 vs L5: An L4 candidate often computes QPS and storage and stops. An L5 candidate notices the 46K/s fan-out number and lets it drive the design.

Step 3: API

POST /v1/posts
  body: { text, media_ids[], idempotency_key }
  -> 201 { post_id, created_at }

GET /v1/feed?cursor={post_id}&limit=20
  -> 200 { items: [ { post_id, author, text, media_urls[], created_at } ], next_cursor }

POST   /v1/users/{user_id}/follow     -> 204
DELETE /v1/users/{user_id}/follow     -> 204

POST /v1/media/upload-url
  -> 200 { media_id, presigned_url }   // client uploads directly to object storage

Design notes worth saying out loud:

Cursor pagination using the last post ID. Offset pagination breaks when new posts arrive at the top while you scroll.
Idempotency key on post creation so a flaky mobile network doesn't create duplicate posts.
Pre-signed upload URLs so large media goes straight to object storage, not through our app servers.

Step 4: Data Model

Store	Key / schema	Why
Users (relational)	`users(user_id PK, name, avatar_url, follower_count, …)`	Small, relational, rarely written
Follows (sharded relational or wide-column)	`following(follower_id, followee_id, created_at)` and `followers(followee_id, follower_id, created_at)`	Two copies, one per query direction, each sharded by its first column
Posts (wide-column, e.g., Cassandra)	`posts(post_id PK, author_id, text, media_keys, created_at)`	Hydration by ID; huge, append-heavy
User timeline (wide-column)	partition `author_id`, clustering `post_id DESC`	"Latest posts by author X," used for celebrity pull and feed rebuilds
Feed cache (Redis)	`feed:{user_id}` → sorted set of `post_id`, scored by time	Precomputed home feed
Post cache (Redis/Memcached)	`post:{post_id}` → serialized post	Fast hydration of feed items
Media (object storage + CDN)	`media/{media_id}/{size}.jpg`	Blobs don't belong in a database

Post IDs are Snowflake-style 64-bit IDs: time-sortable, unique across shards, and directly usable as feed scores and pagination cursors.

Step 5: High-Level Design

Write path (create a post):

Client uploads media using a pre-signed URL, then calls POST /v1/posts.
API gateway authenticates and rate-limits the request.
Post Service generates a post ID, writes to the Posts DB and the author's user timeline, and publishes a PostCreated event to Kafka. It returns success to the client right away.
Fan-out workers consume the event, look up the author's followers in the Social Graph, and add the post ID to each follower's feed cache (ZADD feed:{follower} {post_id} {post_id}), trimming each set to the latest 500 entries.

Read path (load the feed):

Client calls GET /v1/feed.
Feed Service reads the top N post IDs from feed:{user_id} (starting after the cursor).
It merges in recent posts from any celebrities the user follows (more on that below).
It hydrates IDs into full posts with one multi-get against the Post Cache (falling back to the Posts DB on misses), filters deleted or blocked content, and returns the page with media URLs pointing at the CDN.

At this point, we have a design that works. Now let's make it survive real traffic.

Step 6: Deep Dives

Deep Dive 1: Fan-out on Write vs Fan-out on Read

This is the core decision in any feed design, so present all three options.

Fan-out on write (push): precompute every follower's feed at post time. Reads are a single cache lookup, which is ideal for our 35K peak read QPS. But a user with 50M followers would trigger 50M writes for one post, and much of that work is wasted on followers who won't open the app today.
Fan-out on read (pull): compute the feed when the user opens the app by fetching recent posts from everyone they follow and merging. Writes are cheap, but each feed load becomes hundreds of queries plus a merge. That's very hard to keep under 200 ms at p99.
Hybrid (my choice): push for normal accounts and pull for celebrities. If an author has more than a threshold of followers (say ~10K–100K, tuned from real data), the fan-out workers skip them. At read time, the Feed Service fetches recent posts from the handful of celebrities the user follows (from the user timeline table, heavily cached) and merges them in.

Two extra optimizations worth mentioning:

Only fan out to active users. Skip followers who haven't logged in for, say, 30 days. When an inactive user returns, rebuild their feed with a one-time pull. This can cut fan-out volume dramatically.
Prioritize fan-out. Use separate Kafka topics or priority lanes so a viral post's fan-out doesn't delay everyone else's.

L5 vs L6: An L5 candidate lands on the hybrid approach and explains the threshold. An L6 candidate also talks about how to choose and tune the threshold with data, what the write amplification costs in Redis memory and dollars, and how to migrate an account that crosses the threshold without double-delivering posts.

Deep Dive 2: The Feed Read Path and the 200 ms Budget

Let's budget the p99:

Gateway + auth: ~10 ms
Feed cache read (ZREVRANGEBYSCORE, 20–50 IDs): ~1–2 ms
Celebrity merge (cached user timelines for ~5–20 celebrities): ~5–10 ms
Post hydration (one batched multi-get of ~20–50 posts): ~5 ms
Filtering, light ranking, serialization: ~20–40 ms
Network to client: varies, but outside our server-side budget

That's comfortably under 200 ms server-side, if the caches hit. So the real questions are about misses:

Feed cache miss (new or returning user): fall back to a pull-based rebuild, return the first page, and write the rebuilt feed to cache asynchronously.
Post cache miss: batch-read from the Posts DB. Keep the post cache hit rate above ~95% by caching recent posts aggressively; most feed reads are for posts less than 48 hours old.

Deep Dive 3: Hot Keys and Celebrities

A viral post from a celebrity means millions of reads for the same post:{id} key, which all land on a single Redis shard.

Mitigations:

Replicate hot keys across several cache nodes (e.g., post:{id}#1 … #8) and pick one at random on read.
Local in-process cache (a few seconds TTL) on the Feed Service instances for the hottest posts.
Request coalescing: if 1,000 requests miss the same key at once, only one goes to the database.

Deep Dive 4: Consistency and Ordering

Followers: eventual consistency is fine. If fan-out takes 2–5 seconds, nobody notices.
Author: must see their own post instantly. Fix it by having the Feed Service always merge the author's own last few posts (from the user timeline) into their feed, or by synchronously writing to the author's own feed key before returning.
Ordering: Snowflake IDs give us roughly time-ordered keys across shards. For a chronological feed, that's enough. For a ranked feed, ordering comes from the ranker instead.
Deletes and privacy changes: don't try to remove a deleted post from millions of feed caches. Mark it deleted (a tombstone) and filter at hydration time. The same goes for blocks and account deactivations.

Deep Dive 5: Ranking (if the Interviewer Asks)

Most real feeds aren't purely chronological. The standard approach is two-stage:

Candidate generation: the precomputed feed (plus celebrity posts, plus maybe some recommended content) gives you a few hundred candidates.
Ranking: a model scores each candidate on predicted engagement (likes, comments, dwell time) using features like author affinity, post age, and content type. You return the top 20.

Keep features in a low-latency feature store, and keep ranking within your latency budget. If the ranker is slow or down, fall back to chronological. That's graceful degradation, and it's exactly the kind of detail senior interviewers look for.

Step 7: Bottlenecks, Failures, and Monitoring

What fails	Impact	Mitigation
A fan-out worker crashes	Some feeds update late	Kafka retains events; another worker resumes from the committed offset. `ZADD` is idempotent, so replays are safe.
Kafka lag spikes (viral post)	Fan-out delayed for everyone	Autoscale consumers on lag; separate topic for high-follower authors
Feed cache node dies	Those users see cache misses	Redis replicas with automatic failover; fall back to pull-based rebuild
Posts DB partition slow	Hydration misses get slow	Post cache absorbs most reads; timeouts + serve partial feed
Ranking service down	No ranked feed	Fall back to chronological order
Region outage	Users in that region affected	Multi-region deployment; route to nearest healthy region; async cross-region replication

What I'd monitor: feed p50/p99 latency, cache hit ratios (feed and post), Kafka consumer lag, fan-out throughput, error rates per endpoint, and a business metric like "time from post creation to appearing in followers' feeds."

What I'd add with more time: likes and comments counters (with sharded counters to avoid hot rows), notifications, content moderation, and multi-region active-active.

How the Same Answer Looks at L4, L5, and L6

L4: Gets to a working design with a cache and a database. Mentions fan-out on write. May need hints about celebrities. Solid API and data model.
L5: Everything above, plus drives the conversation unprompted, uses the fan-out number from estimation to justify the hybrid model, handles hot keys and read-your-writes, and walks through failures.
L6: Everything above, plus questions the requirements ("Is chronological really what the product wants?"), discusses cost (Redis memory, Kafka throughput), plans how to roll out ranking safely, and is explicit about what to build in v1 versus later.

Want more problems worked through this way? Grokking the System Design Interview applies this same framework to the classic questions, including Designing Facebook's Newsfeed, Designing Twitter, and Designing Instagram. If you're targeting L5/L6 roles, Grokking the System Design Interview, Volume II goes deeper into harder problems like payment systems and notification systems, with more advanced trade-offs.

Bonus: A Template for AI System Design Questions

Because AI questions are now common in general backend loops, here's a compact template for prompts like "Design a customer support chatbot over our docs" or "Design ChatGPT."

Requirements to clarify: Who are the users and what's the volume (requests/day, tokens per request)? Latency target for the first token versus the full response? Accuracy expectations, and is a wrong answer worse than "I don't know"? Data freshness? Privacy and tenant isolation? Budget per request?

The core components:

Ingestion pipeline: pull documents, clean them, split them into chunks, and create embeddings. This is batch or streaming work, usually triggered by a queue.
Vector store + metadata store: store embeddings for semantic search, with filters (tenant, permissions, freshness).
Retrieval + reranking: hybrid search (vector + keyword), then a reranker to pick the best few chunks.
LLM gateway: routes to the right model, enforces rate limits and quotas, retries, and falls back to cheaper or alternate models.
Generation with streaming: stream tokens to the client (SSE or WebSockets) so the user sees the first token quickly.
Guardrails: input and output filtering, PII redaction, prompt-injection defenses.
Caching: exact-match and semantic caching of common questions to cut cost and latency.
Evaluation + feedback loop: offline eval sets, online thumbs up/down, tracing of every request (prompt, retrieved chunks, output).

The numbers that matter: tokens per request, tokens per second per GPU, cost per 1K tokens, time to first token, and GPU utilization. A quick estimate like "1M requests/day × 2K tokens = 2B tokens/day" immediately tells you whether to self-host or call a hosted API.

The trade-offs to discuss: bigger model versus smaller model + better retrieval; latency versus quality (reranking adds tens to hundreds of milliseconds); freshness versus indexing cost; and how to fail safely when retrieval finds nothing.

I go into these question types in AI System Design Interview Questions: ChatGPT, RAG, LLM Inference, and Agents. For full, structured coverage, Grokking the AI System Design Interview covers ML product design, LLM and RAG architectures, and agentic systems, and there's a dedicated walkthrough of Design ChatGPT.

The Most Common System Design Interview Questions

You can't practice every question, but you can practice the patterns behind them. Most questions fall into a handful of families. Master one or two from each and you'll recognize the shape of almost anything you're asked.

Pattern family	Representative questions	Key concept tested
Read-heavy + caching	URL shortener, Pastebin, typeahead	Caching, ID generation, key-value stores
Feeds + fan-out	News feed, Twitter timeline, Instagram	Push vs pull, hot keys
Real-time messaging	Facebook Messenger, Slack, presence	WebSockets, ordering, delivery guarantees
Media + storage	YouTube / Netflix, Dropbox	Object storage, CDN, chunked upload, transcoding
Geospatial	Uber backend, Yelp, food delivery	Geohash/quadtree, location updates
Contention + correctness	Ticketmaster, payment system, flash sales	Locking, idempotency, strong consistency
Infrastructure	Rate limiter, key-value store, distributed queue	Partitioning, replication, consensus
Async pipelines	Notification system, web crawler, ad click aggregator	Queues, retries, stream processing
AI systems	ChatGPT, RAG chatbot, recommendation feed	Retrieval, model serving, cost

For a full list ordered by difficulty, see 64 System Design Interview Questions, Ranked From Easiest to Hardest, and for how to approach the most-asked ones, Top System Design Interview Questions and How to Tackle Them.

12 Mistakes That Sink Strong Candidates

I've seen excellent engineers fail system design rounds for reasons that had nothing to do with their ability. These are the most common ones.

Jumping straight into boxes. Designing before clarifying requirements is the most common mistake, and interviewers notice it in the first two minutes.
Asking questions without proposing answers. "How many users?" is fine. "I'll assume 100M DAU, read-heavy, does that sound right?" is better.
Estimation theater. Ten minutes of arithmetic that never influences a decision.
Buzzword architecture. Kafka, Kubernetes, and microservices everywhere, with no reason given. Every component needs a "because."
Going deep too early. Spending 20 minutes on database internals before you have an end-to-end design.
Staying shallow everywhere. The opposite problem: a complete diagram with no depth anywhere. Pick two or three areas and go deep.
Presenting one option as the only option. Senior candidates compare alternatives before committing.
Ignoring failure. Never asking "what happens when this dies?"
Forgetting the data model. Many designs fall apart because nobody decided how data is keyed and partitioned.
Not listening to hints. When the interviewer says "What about users with millions of followers?", that's not small talk. It's the deep dive they want.
Going silent. The interviewer can only grade what they hear. Think out loud.
Memorizing instead of understanding. A memorized answer collapses the moment the interviewer adds a twist ("Now make it work across three regions").

I cover the misconceptions behind many of these in The 9 Things Engineers Get Wrong About the System Design Interview.

An 8-Week Preparation Plan

Here's a realistic plan for a working engineer with about 6 to 8 hours a week. If you already build distributed systems at work, you can compress it to about four weeks.

Weeks 1–2: Fundamentals. Work through the 15 concepts in this guide. For each, make sure you can explain what it is, when to use it, and what it costs. Use the System Design Cheat Sheet as a checklist.

Weeks 3–4: Framework + classics. Practice the 7-step framework on four or five classic problems: URL shortener, rate limiter, news feed, chat, and file storage. Do one estimation drill (about 10 minutes) every day. After each problem, write a one-page summary of the key decisions.

Weeks 5–6: Depth + modern topics. Move to harder problems (Ticketmaster, payments, notifications, a distributed key-value store) and modern topics (stream processing, sagas, AI systems). Focus on deep dives and failure handling. If you're preparing for microservices-heavy roles, Grokking Microservices for System Design Interviews covers when microservices are (and aren't) the right call and how to defend that choice.

Weeks 7–8: Mocks + polish. Do two or three timed mock interviews a week, ideally with someone who has interviewed candidates before. Record yourself. Practice the first five minutes until they're automatic. If you don't have a practice partner, our mock interviews pair you with engineers from big tech companies who give you rubric-based feedback.

For more detail on timelines by experience level, read How Long Does It Take to Prepare for a System Design Interview?. And if you're starting from zero, How to Learn System Design From Scratch is a good first read.

Best Resources to Prepare

These are the resources I'd recommend, grouped by where you are in your prep. Full disclosure again: the courses are ours at DesignGurus.io, and I built them for exactly this interview.

Courses

Grokking the System Design Interview: the original course. It teaches the 7-step framework and applies it to the classic questions. Start here if you have an interview coming up.
Grokking System Design Fundamentals: for beginners. Covers scaling, load balancing, caching, databases, and CAP from the ground up.
Grokking Scalable Systems for Interviews: for people who know the definitions but struggle to apply them. Caching, sharding, replication, observability, and fault tolerance as design decisions.
Grokking the System Design Interview, Volume II: for L5/L6 candidates. Harder problems and deeper trade-offs.
Grokking the AI System Design Interview: ML products, LLM and RAG architectures, and agentic systems.
Grokking Microservices for System Design Interviews: when microservices are the right call, and how to defend that choice in an interview.

Free articles from the DesignGurus.io blog

Related guide: The Complete System Design Interview Guide for 2027, my complete write-up of the 2027 interview: the framework, what interviewers score, and a full worked example.

Video: the Design Gurus YouTube channel has short explainers on caching, Kafka, consistent hashing, idempotency, and more, plus full walkthroughs like How to answer any system design interview question.

Books and papers: Designing Data-Intensive Applications by Martin Kleppmann is the best single book on the underlying concepts. The Amazon Dynamo, Google Bigtable, and Google Spanner papers are worth skimming once you know the basics.

FAQ

How long should I prepare for a system design interview?

Most working engineers need 4 to 8 weeks at 6 to 8 hours a week. If you already work on distributed systems, 2 to 4 weeks of focused practice on the framework and mock interviews is often enough. If you're new to backend systems, plan for 8 to 12 weeks and start with fundamentals.

Do I need distributed systems experience to pass?

No. Interviewers test reasoning, not résumé items. Many candidates pass after learning the building blocks and practicing the framework on 10–15 problems. What you can't fake is the ability to explain why you chose something, so focus on trade-offs, not memorization.

Are system design interviews asked for junior and new-grad roles?

Less often, and with a lower bar. Some companies include a lighter design round or an object-oriented design round for new grads. For mid-level (L4) roles and above, expect at least one system design round. For senior and staff roles, it's often the most important round in the loop.

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

Say so, and reason from first principles. "I haven't used Cassandra in production, but if it's a leaderless, partitioned wide-column store, then I'd expect writes to be cheap and cross-partition queries to be expensive, so I'd model the data around the partition key." That's a strong answer.

Should I memorize designs for popular questions?

Memorize patterns, not answers. Know the shape of a feed, a chat system, a rate limiter, and a booking system. Then adapt to the specific requirements you're given. Interviewers often add a twist precisely to see whether you're reciting.

How do I practice system design on my own?

Pick a question, set a 45-minute timer, and talk through it out loud while drawing (recording yourself helps a lot). Then compare your design with a reference solution and note what you missed. Do at least a few mocks with another person, because handling interruptions and hints is a separate skill.

How are AI tools changing the system design interview?

Two ways. First, AI system design questions (RAG, LLM serving, agents) are now common, so learn the basic components and cost math. Second, some companies have started allowing AI assistance in parts of their loops. Rules vary by company, so ask your recruiter. Either way, the judgment calls (what to build, what to trade off, and why) are still yours to make and explain.

What's the single most important thing to get right?

The first 15 minutes. Clear requirements, quick estimates, a clean API, and a sensible data model make everything after them easier, and they're the part most candidates rush.

Final Thoughts

The system design interview rewards a specific kind of thinking: start from requirements, let numbers guide decisions, keep the design as simple as the problem allows, and be honest about trade-offs. That's also what good engineering looks like on the job, which is why companies keep using this interview.

If you take one thing from this playbook, make it the framework. Practice it on ten problems, out loud, under a timer. By the tenth, you'll notice that the questions stop feeling like ten different problems and start looking like variations on a few patterns you already know.

Good luck. If this helped, share it with someone who's preparing, and tell me in the comments which question you'd like me to work through next.

— Arslan

Grokking the System Design Interview: How to Design a Rate Limiter (Step by Step)

Arslan Ahmad — Tue, 06 Oct 2026 08:09:16 +0000

"Design a rate limiter."

It sounds small. It is not.

This question shows up at Stripe, Google, Amazon, Cloudflare, and almost every company that runs a public API. It is short enough to fit in 45 minutes. But it is deep enough to separate a junior answer from a senior one.

In this post, I will walk through the problem the way we teach it in Grokking the System Design Interview. Step by step. Requirements first, then estimates, then algorithms, then architecture, then the hard parts. If you are new to this interview format, The Complete System Design Interview Guide for 2027 covers the full framework; this post applies it to one question.

Let's go.

What Is a Rate Limiter?

A rate limiter controls how many requests a client can send in a given time window.

If a user is allowed 100 requests per minute, request number 101 gets rejected. Usually with an HTTP 429 Too Many Requests response.

Think of it like a nightclub bouncer with a clicker. The club holds 200 people. The bouncer counts everyone who walks in. When the counter hits 200, the next person waits outside. Nobody is being rude. The building just has a limit.

Rate limiters exist for three main reasons:

Protect your servers. One buggy script or one bad actor should not take down the whole service.
Control costs. If every request hits a paid third-party API, unlimited traffic means an unlimited bill.
Keep things fair. One heavy user should not slow the system down for everyone else.

Step 1: Clarify the Requirements

Never start drawing boxes right away. Ask questions first. In a real interview, this is where you earn your first points.

Here are the questions I would ask:

Client-side or server-side? Server-side. Client-side limits are easy to bypass.
What do we limit by? User ID, IP address, API key, or a mix. Let's support all of them through configurable rules.
What scale? Think large. Millions of users, a few hundred thousand requests per second at peak.
Distributed? Yes. Many API servers sit behind a load balancer. The limit must hold across all of them.
What happens when a request is throttled? Return 429 with headers that tell the client when to retry.
Hard or soft limit? Mostly hard. A tiny overshoot during a race is acceptable if it keeps latency low.

From those answers, we can write the requirements down.

Functional requirements

Limit requests per client based on configurable rules (for example, 100 requests per minute per user).
Return 429 when a client exceeds the limit.
Tell the client its remaining quota through response headers.

Non-functional requirements

Low latency. The check sits on every request. It must add only a millisecond or two.
Highly available. If the rate limiter breaks, the API should not break with it.
Accurate enough. Small errors are fine. Letting 10x the limit through is not.
Scalable. Works across many servers and regions.

Step 2: Back-of-the-Envelope Estimates

Let's keep the math simple.

10 million daily active users.
Peak traffic of 200,000 requests per second.
Each counter needs a key (about 50 bytes) plus a count and a timestamp (about 16 bytes). Call it roughly 100 bytes with overhead.

Memory for 10 million active counters:

10,000,000 x 100 bytes = 1 GB

That fits in memory on a single Redis node. But 200,000 checks per second, with a read and a write each, is better spread across a small Redis cluster. That also gives us replication for availability.

The takeaway: storage is cheap here. Latency and coordination are the real problems.

Step 3: Pick a Rate Limiting Algorithm

This is the heart of the interview. There are five classic algorithms. You do not need all of them in detail, but you should know the trade-offs.

1. Token Bucket

A bucket holds tokens. Tokens refill at a fixed rate. Every request takes one token. No token, no entry.

Bucket size = how big a burst you allow.
Refill rate = your long-term average limit.

Pros: Simple. Memory efficient. Allows short bursts, which matches real user behavior.

Cons: Two parameters to tune.

This is what Amazon API Gateway and Stripe use. It is the safest default in an interview.

2. Leaky Bucket

Requests enter a queue. The queue drains at a fixed rate, like water leaking from a hole in a bucket. If the queue is full, new requests are dropped.

Pros: Produces a perfectly smooth output rate.

Cons: Bursts of traffic fill the queue with old requests. Recent requests get starved.

Good for systems that need steady processing, like a payment processor that calls a bank API.

3. Fixed Window Counter

Split time into fixed windows, like one minute each. Keep one counter per window. Reject when the counter passes the limit.

Pros: Very simple. One counter per user.

Cons: The edge problem. A user can send 100 requests at 12:00:59 and another 100 at 12:01:00. That is 200 requests in two seconds, double the limit.

4. Sliding Window Log

Store the timestamp of every request. On each new request, drop timestamps older than the window and count what is left.

Pros: Perfectly accurate.

Cons: Memory heavy. A limit of 1,000 requests per hour means storing up to 1,000 timestamps per user.

5. Sliding Window Counter

A hybrid. Keep counters for the current and previous window. Estimate the count with a weighted average.

estimate = current_count + previous_count x (overlap percentage of previous window)

If we are 30% into the current minute, the previous minute still overlaps by 70%. So with 80 requests last minute and 20 so far this minute:

20 + 80 x 0.7 = 76

Pros: Smooths out the edge problem. Memory efficient.

Cons: It is an approximation. Cloudflare measured it at about 0.003% error across 400 million requests, which is more than good enough.

Quick Comparison

Algorithm	Memory	Accuracy	Allows bursts	Best for
Token bucket	Low	Good	Yes	General API limits
Leaky bucket	Low	Good	No (smooths)	Steady downstream calls
Fixed window	Very low	Weak at edges	Yes, at edges	Simple, low-stakes limits
Sliding window log	High	Exact	No	Strict, low-volume limits
Sliding window counter	Low	Very good	Limited	High-scale APIs

What I would say in the interview: "I will go with the token bucket as the default because it is cheap, handles bursts, and is used in production by large API providers. If the business needs strict smoothing, I would switch to sliding window counter."

Step 4: High-Level Design

Now we draw boxes.

Here is the flow:

Client sends a request.
API Gateway / Rate Limiter middleware receives it. This is where the check happens.
The middleware builds a key, like rate:user:42, and checks the counter in Redis.
Rules Service stores the limits (for example, free tier gets 100 per minute, paid tier gets 1,000). The middleware caches these rules locally and refreshes them every few seconds.
If the client is under the limit, the request goes to the API servers.
If not, the middleware returns 429 right away. The backend never sees it.

Where should the rate limiter live?

Three options:

Inside each service. Simple, but every team rebuilds the same logic.
In the API gateway. Central and consistent. This is the common choice.
As a separate service. Flexible, but adds a network hop to every request.

I would pick the API gateway. If the company already runs a gateway like Kong, Envoy, or AWS API Gateway, rate limiting is a plugin away.

Why Redis?

In-memory, so reads and writes take under a millisecond.
Built-in INCR and EXPIRE commands.
Supports Lua scripts, which run atomically. That matters a lot. More on that next.

Response headers

Be kind to clients. Tell them where they stand.

HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1696608000
Retry-After: 30

Good clients read these headers and back off on their own. That reduces load before the limiter even has to say no.

Step 5: Deep Dives (Where Senior Candidates Shine)

A basic design gets you to "hire" at the mid level. These deep dives push you toward senior and staff.

Deep Dive 1: Race Conditions

Picture two API servers handling requests from the same user at the same moment.

Server A reads the counter: 99.
Server B reads the counter: 99.
Both see "under 100" and allow the request.
Both write 100.

Two requests went through. The counter says one. Do this at scale and limits leak badly.

Fix: Make read-check-write a single atomic step. In Redis, use a Lua script. Redis runs each script start to finish without interruption.

Here is a token bucket in Lua:

-- KEYS[1] = bucket key
-- ARGV[1] = capacity, ARGV[2] = refill rate per second, ARGV[3] = now (ms)
local capacity = tonumber(ARGV[1])
local rate = tonumber(ARGV[2])
local now = tonumber(ARGV[3])

local bucket = redis.call("HMGET", KEYS[1], "tokens", "ts")
local tokens = tonumber(bucket[1]) or capacity
local ts = tonumber(bucket[2]) or now

-- refill based on elapsed time
local elapsed = math.max(0, now - ts) / 1000
tokens = math.min(capacity, tokens + elapsed * rate)

local allowed = 0
if tokens >= 1 then
  tokens = tokens - 1
  allowed = 1
end

redis.call("HMSET", KEYS[1], "tokens", tokens, "ts", now)
redis.call("EXPIRE", KEYS[1], math.ceil(capacity / rate) * 2)
return { allowed, math.floor(tokens) }

One network round trip. No races. No locks.

Deep Dive 2: Scaling Redis

One Redis node will not last forever. Shard the keys across a Redis cluster using consistent hashing on the client key. All counters for user:42 land on the same shard, so the Lua script still works.

Add a replica per shard for failover.

Deep Dive 3: What If Redis Goes Down?

This is a favorite follow-up. You have two choices:

Fail open. Let all requests through. The API stays up, but you lose protection for a while.
Fail closed. Reject all requests. You stay protected, but your API is effectively down.

For most products, fail open is the right call. A short window without limits hurts less than a full outage. Pair it with a local in-memory fallback limiter on each gateway node, so you still get rough protection.

For security-critical limits, like login attempts, fail closed may be the safer choice. Say this trade-off out loud. Interviewers love it.

Deep Dive 4: Multi-Region

If you run in three regions, a global limit gets tricky. Syncing every counter across regions on every request adds too much latency.

Common approaches:

Local limits per region. Split the global limit (for example, 1,000 per minute becomes about 333 per region). Simple, slightly inaccurate.
Async sync. Each region counts locally and syncs totals every second or so. Accepts a small overshoot for much lower latency.

Most real systems choose eventual consistency here. Perfect global accuracy is rarely worth the cost.

Deep Dive 5: Reducing Load on Redis

At very high traffic, even Redis can become a hot spot. Two tricks help:

Local pre-check. Each gateway keeps a small in-memory counter and only syncs with Redis in batches.
Hot key handling. A single huge customer can overload one shard. Split their key into sub-keys (rate:user:42:0 to rate:user:42:3) and divide their limit across them.

What Interviewers Actually Look For

Here is how I would grade this question, based on years of running these interviews.

Level	What a strong answer includes
Junior / Mid	Clear requirements, one algorithm explained well, gateway plus Redis design
Senior	Compares algorithms with trade-offs, solves race conditions, discusses fail open vs fail closed
Staff	Multi-region strategy, hot keys, rule management, and how clients should react to `429`

You do not need every deep dive. Pick two and go deep. Depth beats breadth.

Common Mistakes to Avoid

Jumping to Redis before asking a single question.
Explaining five algorithms and never picking one.
Forgetting the race condition.
Ignoring what happens when the rate limiter itself fails.
Storing counters in a relational database. Too slow for a per-request check.

Key Takeaways

A rate limiter caps how many requests a client can make in a time window.
Always clarify: what to limit by, scale, distributed or not, hard or soft limits.
Token bucket is the best default. Sliding window counter is great for high-scale accuracy.
Put the limiter in the API gateway and store counters in Redis.
Use Lua scripts to make the check atomic and avoid race conditions.
Fail open for most APIs. Fail closed for security-critical limits.
For multiple regions, accept small inaccuracy in exchange for low latency.

FAQ

What HTTP status code should a rate limiter return?

429 Too Many Requests, along with a Retry-After header that tells the client when to try again.

Which rate limiting algorithm is best?

There is no single best one. Token bucket is the most common default because it is simple, cheap, and allows short bursts. Sliding window counter is better when you need smoother limits at scale.

Why use Redis instead of a database?

The check runs on every single request. Redis is in-memory and answers in under a millisecond. A disk-based database would add too much latency.

What is the difference between token bucket and leaky bucket?

Token bucket allows bursts up to the bucket size. Leaky bucket smooths everything into a steady output rate, even if requests arrive in bursts.

Should the rate limiter fail open or fail closed?

Usually fail open, so a limiter outage does not become an API outage. For login or payment endpoints, failing closed can be safer.

How long should I spend on this in a 45-minute interview?

About 5 minutes on requirements, 5 on estimates, 10 on algorithms, 10 on the high-level design, and the rest on one or two deep dives.

Wrapping Up

The rate limiter is a great interview question because it looks easy. The candidates who stand out are the ones who slow down, ask the right questions, and talk openly about trade-offs.

If you want the full picture of how this round is scored in 2027, from the framework to the level-by-level expectations, read The Complete System Design Interview Guide for 2027.

If you want more walkthroughs like this one, including URL shorteners, news feeds, and chat systems, they are all covered in Grokking the System Design Interview.

Which system design question should I break down next? Let me know in the comments.

LeetCode Patterns: The Complete List of 20 to Master (With Examples)

Arslan Ahmad — Tue, 06 Oct 2026 04:55:28 +0000

The complete list of 20 LeetCode patterns. Each one carries the signal that identifies it in a problem statement, a code template you can reuse, and three practice problems on LeetCode. Pattern problem counts come from LeetCode's own topic tags.

LeetCode has 4,073 problems. Nobody solves them all, and nobody needs to.

The questions are generated from a much smaller set of reusable approaches. Learn to recognize those, and a problem you have never seen becomes a variation of one you have. Miss them, and every question feels new, which is why solving hundreds of problems at random produces so little.

This guide covers all 20 patterns. For each one you get the cue that gives it away, why it works, a short template in Python, and three real LeetCode problems to practice on. The order is by what each pattern returns against LeetCode's actual problem distribution, so the earliest entries are the ones worth learning first.

You will see these called LeetCode patterns, LC patterns, coding patterns, or DSA patterns. They are the same thing: a reusable approach that pairs an algorithmic technique with the data structure it runs on. A single LeetCode pattern is worth more than a hundred solved problems, because the pattern transfers and the solved problem does not.

If you want the same 20 as a short reference instead, see the coding interview patterns catalog. If you want to train the recognition skill itself rather than read the list, see how to read a problem statement and name the pattern.

All 20 LeetCode Patterns

Two Pointers
Sliding Window
Modified Binary Search
Tree Depth First Search
Tree Breadth First Search
Island (Matrix Traversal)
0/1 Knapsack (Dynamic Programming)
Top 'K' Elements
Backtracking
Subsets
Bitwise XOR
Fast & Slow Pointers
Merge Intervals
Monotonic Stack
Topological Sort
In-place Reversal of a Linked List
Two Heaps
Cyclic Sort
K-way Merge
Multi-threaded

The 20 Patterns at a Glance

Problem counts are LeetCode topic-tag totals, pulled from LeetCode. A few patterns share a tag and two have no dedicated tag, which is noted rather than guessed.

Pattern	Recognize it by	Time	LeetCode problems
1. Two Pointers	sorted input, find a pair or triplet	O(n) time	263
2. Sliding Window	longest or shortest contiguous run	O(n) time	175
3. Modified Binary Search	sorted or rotated, or a testable answer	O(log n) time	356
4. Tree Depth First Search	root-to-leaf path, or a subtree answer	O(n) time	349
5. Tree Breadth First Search	levels, or fewest steps	O(n) time	260
6. Island (Matrix Traversal)	a grid, count connected regions	O(m*n) time	285
7. 0/1 Knapsack (Dynamic Programming)	pick a subset under a capacity	O(n*C) time	684
8. Top 'K' Elements	k largest, smallest, or most frequent	O(n log k) time	222
9. Backtracking	list every valid configuration	O(b^d) time	114
10. Subsets	every combination or power set	O(n * 2^n) time	114
11. Bitwise XOR	values pair off, find the odd one out	O(n) time	297
12. Fast & Slow Pointers	cycle, middle, or kth from the end	O(n) time	263
13. Merge Intervals	ranges or time slots that overlap	O(n log n) time	no dedicated tag
14. Monotonic Stack	next greater or next smaller element	O(n) time	76
15. Topological Sort	prerequisites, ordering, cycle check	O(V+E) time	40
16. In-place Reversal of a Linked List	reverse a list without new memory	O(n) time	82
17. Two Heaps	running median, or a split set	O(log n) insert	222
18. Cyclic Sort	a permutation of 1..n	O(n) time	no dedicated tag
19. K-way Merge	k sorted lists to combine	O(n log k) time	17
20. Multi-threaded	coordinate or order concurrent work	depends on the coordination primitive	9

The Most Common LeetCode Patterns

If you only have time for part of this list, the eight most common LeetCode patterns are the first eight above: Two Pointers, Sliding Window, Modified Binary Search, Tree Depth First Search, Tree Breadth First Search, Island (Matrix Traversal), 0/1 Knapsack, and Top 'K' Elements.

Those eight are also the most important ones to get automatic, because they are the patterns an interviewer is most likely to reach for and the ones whose variations show up across the widest range of questions. Together they account for the large majority of what gets asked in a standard coding loop.

One warning about reading tag counts straight. Bitwise XOR carries 297 tagged problems, which is more than Sliding Window's 175, but almost all of those are narrow puzzles rather than interview staples. A large tag means the technique is common in the problem set, not that it is common in interviews. The order on this page accounts for that; a raw tag ranking does not.

LeetCode Patterns Cheat Sheet: What the Wording Tells You

Pattern recognition is mostly vocabulary. The same phrases appear in problem statements again and again, and each one points at a small number of patterns. Use this as a lookup while you practice, then stop using it once the mapping is automatic.

If the problem says	Reach for
"sorted array" plus "find a pair / triplet"	Two Pointers
"longest" or "shortest" plus "substring" or "subarray"	Sliding Window
"at most K" or "exactly K distinct"	Sliding Window
"rotated sorted array"	Modified Binary Search
"minimum / maximum value such that ..."	Modified Binary Search
"root-to-leaf" or "path sum"	Tree Depth First Search
"level order" or "level by level"	Tree Breadth First Search
"shortest number of steps" on a graph or grid	Tree Breadth First Search
"grid" plus "connected" or "regions" or "islands"	Island (Matrix Traversal)
"can you partition" or "reach exactly this total"	0/1 Knapsack (Dynamic Programming)
"fewest coins" or "ways to make up"	0/1 Knapsack (Dynamic Programming)
"top K" or "K most frequent" or "K closest"	Top 'K' Elements
"all permutations" or "all valid boards"	Backtracking
"all subsets" or "power set" or "all combinations"	Subsets
"every element appears twice except one"	Bitwise XOR
"cycle", "middle node", or "Nth from the end"	Fast & Slow Pointers
"intervals", "meetings", or "time slots"	Merge Intervals
"next greater" or "next smaller" element	Monotonic Stack
"prerequisites", "course order", or "build order"	Topological Sort
"reverse the list" with O(1) extra space	In-place Reversal of a Linked List
"median" of a stream or a window	Two Heaps
"numbers from 1 to n" with one missing or duplicated	Cyclic Sort
"K sorted lists" or "K sorted arrays"	K-way Merge
"threads must run in order"	Multi-threaded

Two cautions. A problem can carry more than one of these signals, in which case the patterns usually compose rather than compete, such as a sliding window over a monotonic stack. And a phrase is evidence, not proof; confirm against the constraints before you commit to an approach.

If you want to train this recognition rather than look it up, this walkthrough reads a problem statement and names the pattern step by step.

Two Pointers

Use it when the input is sorted, or you need a pair, triplet, or subsequence that satisfies a condition.

Two indices moving toward each other turn an O(n^2) scan of every pair into a single O(n) pass, because a sorted order tells you which pointer to move.

def two_sum_sorted(nums, target):
    lo, hi = 0, len(nums) - 1
    while lo < hi:
        s = nums[lo] + nums[hi]
        if s == target:
            return [lo, hi]
        if s < target:
            lo += 1          # need a bigger sum
        else:
            hi -= 1          # need a smaller sum
    return []

Complexity: O(n) time, O(1) space. LeetCode tags 263 problems with two-pointers.

Practice on LeetCode:

Sliding Window

Use it when the question asks for the longest, shortest, or best contiguous subarray or substring.

The window expands to include new elements and contracts to restore the constraint, so each element is visited at most twice instead of being re-scanned for every start index.

def longest_unique(s):
    seen, left, best = {}, 0, 0
    for right, ch in enumerate(s):
        if ch in seen and seen[ch] >= left:
            left = seen[ch] + 1      # contract past the duplicate
        seen[ch] = right
        best = max(best, right - left + 1)
    return best

Complexity: O(n) time, O(k) space. LeetCode tags 175 problems with sliding-window.

Practice on LeetCode:

Modified Binary Search

Use it when the input is sorted or rotated, or the answer itself is a number you can test for feasibility.

Any question where a candidate answer can be checked in O(n) becomes O(n log n) by binary searching the answer space rather than the array.

def search_rotated(nums, target):
    lo, hi = 0, len(nums) - 1
    while lo <= hi:
        mid = (lo + hi) // 2
        if nums[mid] == target:
            return mid
        if nums[lo] <= nums[mid]:            # left half is sorted
            if nums[lo] <= target < nums[mid]:
                hi = mid - 1
            else:
                lo = mid + 1
        else:                                # right half is sorted
            if nums[mid] < target <= nums[hi]:
                lo = mid + 1
            else:
                hi = mid - 1
    return -1

Complexity: O(log n) time, O(1) space. LeetCode tags 356 problems with binary-search.

Practice on LeetCode:

Tree Depth First Search

Use it when the answer depends on a full root-to-leaf path, or on information returned from a subtree.

Recursion carries state down the path and returns an answer back up, which is exactly the shape of path sums, depths, and subtree validity checks.

def has_path_sum(node, target):
    if not node:
        return False
    rest = target - node.val
    if not node.left and not node.right:     # leaf
        return rest == 0
    return has_path_sum(node.left, rest) or has_path_sum(node.right, rest)

Complexity: O(n) time, O(h) space. LeetCode tags 349 problems with depth-first-search.

Practice on LeetCode:

Tree Breadth First Search

Use it when the question mentions levels, or asks for the shortest number of steps.

A queue visits every node at distance k before any node at distance k+1, so the first time you reach a target you have reached it by the shortest route.

from collections import deque

def level_order(root):
    if not root:
        return []
    out, q = [], deque([root])
    while q:
        level = []
        for _ in range(len(q)):              # freeze the level width
            node = q.popleft()
            level.append(node.val)
            if node.left:
                q.append(node.left)
            if node.right:
                q.append(node.right)
        out.append(level)
    return out

Complexity: O(n) time, O(w) space. LeetCode tags 260 problems with breadth-first-search.

Practice on LeetCode:

Island (Matrix Traversal)

Use it when the input is a grid and you need to find or count connected regions.

A grid is a graph whose neighbors are implicit, so one flood fill per unvisited cell counts regions in a single pass over the matrix.

def num_islands(grid):
    if not grid:
        return 0
    rows, cols, count = len(grid), len(grid[0]), 0

    def sink(r, c):
        if r < 0 or c < 0 or r >= rows or c >= cols or grid[r][c] != '1':
            return
        grid[r][c] = '0'                     # mark visited in place
        sink(r + 1, c); sink(r - 1, c); sink(r, c + 1); sink(r, c - 1)

    for r in range(rows):
        for c in range(cols):
            if grid[r][c] == '1':
                count += 1
                sink(r, c)
    return count

Complexity: O(m*n) time, O(m*n) space. LeetCode tags 285 problems with matrix.

Practice on LeetCode:

0/1 Knapsack (Dynamic Programming)

Use it when you must choose a subset under a capacity or budget, and subproblems repeat.

Each item is either taken or skipped, so the answer for a capacity depends only on smaller capacities, which a table fills once instead of re-deriving exponentially.

def can_partition(nums):
    total = sum(nums)
    if total % 2:
        return False
    target = total // 2
    dp = [False] * (target + 1)
    dp[0] = True
    for n in nums:
        for cap in range(target, n - 1, -1):   # backwards: each item once
            dp[cap] = dp[cap] or dp[cap - n]
    return dp[target]

Complexity: O(n*C) time, O(C) space. LeetCode tags 684 problems with dynamic-programming.

Practice on LeetCode:

Top 'K' Elements

Use it when the question asks for the k largest, k smallest, k most frequent, or k closest.

A heap of size k keeps only the candidates that can still win, which costs O(n log k) instead of the O(n log n) of sorting everything.

import heapq

def kth_largest(nums, k):
    heap = []
    for n in nums:
        heapq.heappush(heap, n)
        if len(heap) > k:
            heapq.heappop(heap)              # drop the smallest candidate
    return heap[0]

Complexity: O(n log k) time, O(k) space. LeetCode tags 222 problems with heap-priority-queue.

Practice on LeetCode:

Backtracking

Use it when the question asks for all valid configurations, not just a count or a best one.

You build a candidate one choice at a time and undo the choice on the way out, which explores the whole space while holding only one path in memory.

def permute(nums):
    out, path, used = [], [], [False] * len(nums)

    def walk():
        if len(path) == len(nums):
            out.append(path[:])              # copy, the path mutates
            return
        for i, n in enumerate(nums):
            if used[i]:
                continue
            used[i] = True; path.append(n)
            walk()
            path.pop(); used[i] = False      # undo
    walk()
    return out

Complexity: O(b^d) time, O(d) space. LeetCode tags 114 problems with backtracking, and it shares the backtracking tag with Subsets.

Practice on LeetCode:

Subsets

Use it when you need every combination, subset, or power set of the input.

Each element is in or out, so the answer set doubles per element, and you can build it iteratively by cloning what you already have.

def subsets(nums):
    out = [[]]
    for n in nums:
        out += [cur + [n] for cur in out]    # clone everything, add n
    return out

Complexity: O(n * 2^n) time, O(n * 2^n) space. LeetCode tags 114 problems with backtracking, and it shares the backtracking tag with Backtracking.

Practice on LeetCode:

Bitwise XOR

Use it when elements pair up and cancel, or you are asked to find a single missing or unique value.

XOR of a value with itself is zero and XOR is order independent, so every duplicate cancels and the lone survivor is the answer in O(1) space.

def single_number(nums):
    out = 0
    for n in nums:
        out ^= n                             # pairs cancel to 0
    return out

Complexity: O(n) time, O(1) space. LeetCode tags 297 problems with bit-manipulation.

Practice on LeetCode:

Fast & Slow Pointers

Use it when the input is a linked list or an implicit sequence, and you need a cycle, a middle, or a kth-from-end node.

Two pointers at different speeds meet inside a cycle and land the slow one at the middle on a straight run, with no extra memory.

def has_cycle(head):
    slow = fast = head
    while fast and fast.next:
        slow = slow.next                     # one step
        fast = fast.next.next                # two steps
        if slow is fast:
            return True
    return False

Complexity: O(n) time, O(1) space. LeetCode tags 263 problems with two-pointers, and it shares the two-pointers tag with Two Pointers.

Practice on LeetCode:

Merge Intervals

Use it when the input is a list of ranges, meetings, or time slots that may overlap.

Once intervals are sorted by start, every overlap is adjacent, so one pass merges or counts them without comparing all pairs.

def merge(intervals):
    intervals.sort(key=lambda iv: iv[0])
    out = []
    for start, end in intervals:
        if out and start <= out[-1][1]:      # overlaps the previous
            out[-1][1] = max(out[-1][1], end)
        else:
            out.append([start, end])
    return out

Complexity: O(n log n) time, O(n) space. LeetCode has no dedicated tag for this one; these sit under array and sorting.

Practice on LeetCode:

Monotonic Stack

Use it when you need the next greater or next smaller element, or the span a value dominates.

A stack kept in sorted order discards elements that can never be an answer again, so every element is pushed and popped at most once.

def daily_temperatures(temps):
    out, stack = [0] * len(temps), []        # stack holds indices
    for i, t in enumerate(temps):
        while stack and temps[stack[-1]] < t:
            j = stack.pop()
            out[j] = i - j
        stack.append(i)
    return out

Complexity: O(n) time, O(n) space. LeetCode tags 76 problems with monotonic-stack.

Practice on LeetCode:

Topological Sort

Use it when tasks, courses, or builds have prerequisites, and you need a valid order or a cycle check.

Repeatedly removing nodes with no remaining prerequisites produces a legal order, and a leftover node proves a cycle exists.

from collections import deque

def find_order(n, prereqs):
    graph, indeg = [[] for _ in range(n)], [0] * n
    for course, need in prereqs:
        graph[need].append(course)
        indeg[course] += 1
    q = deque(i for i in range(n) if indeg[i] == 0)
    out = []
    while q:
        node = q.popleft()
        out.append(node)
        for nxt in graph[node]:
            indeg[nxt] -= 1
            if indeg[nxt] == 0:
                q.append(nxt)
    return out if len(out) == n else []      # short means a cycle

Complexity: O(V+E) time, O(V+E) space. LeetCode tags 40 problems with topological-sort.

Practice on LeetCode:

In-place Reversal of a Linked List

Use it when you must reverse a list or a sublist without allocating a new one.

Rewiring the next pointer of each node as you walk reverses the list in one pass and O(1) extra space.

def reverse_list(head):
    prev, cur = None, head
    while cur:
        nxt = cur.next                       # save before overwriting
        cur.next = prev
        prev, cur = cur, nxt
    return prev

Complexity: O(n) time, O(1) space. LeetCode tags 82 problems with linked-list.

Practice on LeetCode:

Two Heaps

Use it when you need a running median, or to keep a set split into a smaller half and a larger half.

A max-heap over the low half and a min-heap over the high half put the middle value at the two tops, so the median is O(1) to read.

import heapq

class MedianFinder:
    def __init__(self):
        self.low, self.high = [], []         # low is a max-heap (negated)

    def add(self, num):
        heapq.heappush(self.low, -num)
        heapq.heappush(self.high, -heapq.heappop(self.low))
        if len(self.high) > len(self.low):
            heapq.heappush(self.low, -heapq.heappop(self.high))

    def median(self):
        if len(self.low) > len(self.high):
            return -self.low[0]
        return (-self.low[0] + self.high[0]) / 2

Complexity: O(log n) insert, O(1) median. LeetCode tags 222 problems with heap-priority-queue, and it shares the heap tag with Top 'K' Elements.

Practice on LeetCode:

Cyclic Sort

Use it when the input is a permutation of numbers in a known range such as 1 to n.

When a value implies its own index, swapping each number home sorts the array in O(n) with no extra space, which exposes missing and duplicate values.

def cyclic_sort(nums):
    i = 0
    while i < len(nums):
        home = nums[i] - 1                   # value n belongs at index n-1
        if 0 <= home < len(nums) and nums[i] != nums[home]:
            nums[i], nums[home] = nums[home], nums[i]
        else:
            i += 1
    return nums

Complexity: O(n) time, O(1) space. LeetCode has no dedicated tag for this one; these sit under array and sorting.

Practice on LeetCode:

K-way Merge

Use it when you are given k sorted lists, arrays, or streams to combine or search across.

A heap holding one candidate from each list always exposes the global smallest next element, so the merge costs O(n log k).

import heapq

def merge_k_sorted(lists):
    heap = [(lst[0], i, 0) for i, lst in enumerate(lists) if lst]
    heapq.heapify(heap)
    out = []
    while heap:
        val, li, idx = heapq.heappop(heap)
        out.append(val)
        if idx + 1 < len(lists[li]):         # refill from the same list
            heapq.heappush(heap, (lists[li][idx + 1], li, idx + 1))
    return out

Complexity: O(n log k) time, O(k) space. LeetCode tags 17 problems with merge-sort.

Practice on LeetCode:

Multi-threaded

Use it when the question asks you to coordinate concurrent work, or to enforce an order between threads.

The algorithm is usually trivial; what is graded is whether you reach for the right primitive and avoid a race or a deadlock.

import threading

class Foo:
    def __init__(self):
        self.second = threading.Semaphore(0)
        self.third = threading.Semaphore(0)

    def first(self, printFirst):
        printFirst()
        self.second.release()                # unblock the next stage

    def second_(self, printSecond):
        self.second.acquire()
        printSecond()
        self.third.release()

    def third_(self, printThird):
        self.third.acquire()
        printThird()

Complexity: depends on the coordination primitive. LeetCode tags 9 problems with concurrency.

Practice on LeetCode:

Which LeetCode Patterns Are Most Important

This is the part most pattern lists leave out. Not every pattern earns the same return, because LeetCode's own problems are not evenly spread across them.

Every question on LeetCode carries one or more topic tags. Counting those tags shows where the problems actually are, which is a better guide to study order than any opinion. Here are the 20 largest tags across the 4,073 problems.

LeetCode topic tag	Problems
Array	2273
String	895
Hash Table	843
Dynamic Programming	684
Sorting	540
Greedy	483
Binary Search	356
Depth-First Search	349
Bit Manipulation	297
Matrix	285
Prefix Sum	277
Tree	270
Two Pointers	263
Breadth-First Search	260
Heap (Priority Queue)	222
Graph	190
Stack	182
Sliding Window	175
Backtracking	114
Union Find	98

Three things follow from this.

Array, String, and Hash Table are not patterns, they are the surface. They head the list because almost everything is phrased in terms of them. What matters is the technique applied to them, which is why Two Pointers and Sliding Window carry so much weight despite smaller tag counts.

A small set of patterns covers most of the volume. Two Pointers, Sliding Window, Modified Binary Search, the two tree traversals, and Dynamic Programming together account for more tagged problems than the rest of this list combined. If your preparation time is short, those are the ones to install first.

The long tail is still worth knowing, but last. K-way Merge has 17 tagged problems and Multi-threaded has 9. They are rare, and they are also the ones candidates most often have no answer for. Learn them when the common patterns are automatic, not before.

How This Compares With the Other LeetCode Pattern Lists

Three resources come up whenever people look for this, and they are all worth knowing about. They do different jobs, and two of them are free.

Sean Prashad's Leetcode Patterns

seanprashad.com/leetcode-patterns is a free, open source list, and it is the most widely used of the three. Its repository describes it as "a pattern-based approach to learn technical interview questions" and carries 14,117 stars.

What it gives you is a curated set of 179 problems you can filter by difficulty, by company, and by pattern, plus a condition-to-approach table that maps a problem characteristic to a suggested technique. It is excellent for deciding what to solve next, and for working a company-specific list before an onsite.

What it does not do is teach the patterns. The labels it sorts by are mostly LeetCode's own topic tags, around 75 of them, so "Array" and "Hash Table" sit alongside "Sliding Window". If you already know the patterns, that is exactly what you want. If you are trying to learn them, a list cannot explain why a window contracts or when binary search applies to an answer rather than an array.

AlgoMaster's 15 Patterns

AlgoMaster's post covers 15 patterns, each with a diagram, a one-line note on when to use it, and three linked LeetCode problems. It is well made and it is the piece most people have read on this topic.

It stops short of code. There is no template for any of the 15, so you get the idea of a pattern without the implementation you would actually write under time pressure.

NeetCode

NeetCode is a roadmap built around curated problem lists with solution walkthroughs, and it is the strongest option if you prefer to learn by watching rather than reading. We cover it separately rather than summarize it here: the NeetCode roadmap on one page maps the pattern behind each topic, and NeetCode compared with LeetCode puts the numbers side by side.

Where this page fits

This one is the explained version. Every pattern gets the cue that identifies it, why the technique works, a template in Python, a diagram, and three problems, so you can go from never having seen a pattern to writing it from memory without leaving the page.

Use whichever fits what you need right now. If you want a filterable queue of problems, use Sean Prashad's list. If you want video, use NeetCode. If you want to understand the 20 patterns well enough to recognize them on a question you have never seen, read this page and then practice against one of those lists. They work well together, and a free list plus a real explanation beats either on its own.

For a wider view of the paid and free options, including the video courses, see the best DSA courses compared.

How to Use This List

Work one pattern at a time rather than one problem at a time. Read the cue, write the template from memory, then solve the three linked problems in a row. Practicing LeetCode problems pattern wise, meaning grouped by the pattern that solves them rather than in list order, teaches you more than solving ten unrelated ones, because the third problem in a group is where recognition starts to happen on its own.

That is why the 60 problems on this page are grouped under their pattern instead of being given as one flat list. A flat list trains you to grind. Problems grouped by pattern train you to recognize.

When a problem defeats you, do not jump straight to the solution. Ask which of these 20 it resembles first. If you can name the pattern and still cannot finish, that is a template problem and it is quick to fix. If you cannot name the pattern at all, that is the skill actually being tested, and it is the one worth practicing.

The full curriculum, with each pattern taught in six languages and grouped practice problems, is in Grokking the Coding Interview.

Check out Blind75 for more problems. If you are choosing a course to learn these patterns from, The Best DSA Courses Compared: Paid, Free, and YouTube reviews the main options side by side.

FAQs - LeetCode Patterns and Interview Prep

Q1. What are LeetCode patterns?

LeetCode patterns are common coding techniques or strategies that repeatedly show up in LeetCode problems and technical interviews. Instead of solving every problem from scratch, learning these patterns helps you recognize how to approach and solve new problems based on familiar logic (e.g., Two Pointers, Sliding Window, DFS, etc.).

Q2. Why should I learn LeetCode patterns instead of solving random problems?

Focusing on patterns helps you avoid burnout and prepares you faster. Each pattern unlocks the ability to solve dozens of problems, which is much more efficient than solving 500+ random questions without structure. Interviewers often test your ability to apply known patterns to new scenarios, not just memorize solutions.

Q3. How many LeetCode patterns should I learn for FAANG interviews?

Learn all 20, in the order on this page. The first six, Two Pointers, Sliding Window, Modified Binary Search, the two tree traversals, and Dynamic Programming, cover the largest share of what gets asked, so start there if your time is short. The remaining fourteen are what separate a candidate who handles the common question from one who is not stopped by an unusual one.

Q4. Do LeetCode patterns actually help in real interviews?

Yes, most FAANG interview questions map to well-known patterns. Recognizing the right pattern during an interview helps you solve problems faster and with more confidence, especially under time pressure. It also shows your structured thinking, which is exactly what interviewers want.

Q5. Where can I practice LeetCode patterns?

You can start with categorized problem lists on LeetCode itself, or check out structured resources like Grokking the Coding Interview, which teaches these patterns with guided explanations and practice problems grouped by pattern.

Q6. Are LeetCode patterns the same as algorithms?

Not exactly. Algorithms are step-by-step procedures for solving specific types of problems (like Dijkstra’s or Merge Sort). Patterns are reusable problem-solving approaches, like frameworks, that help you decide how to apply different algorithms or data structures depending on the question.

Q7. How do I identify which pattern a question belongs to?

Look at the problem constraints and the goal. For example:

Need to find a subarray or substring? → Try Sliding Window
Working with sorted data or binary decisions? → Use Binary Search
Need to explore all paths or combinations? → Think DFS or Backtracking

The more patterns you practice, the easier it becomes to recognize which one fits.

Q8. Is mastering patterns enough to crack coding interviews?

Patterns are your foundation, but combine them with good communication, mock interviews, and time management. You should also review system design (for senior roles), behavioral interview questions, and understand the company’s specific process.

Q9. What are the best LeetCode patterns to know?

The best LeetCode patterns to focus on are the ones that appear most frequently in coding interviews and help solve a wide variety of problems. These include:

Two Pointers – great for arrays and strings
Sliding Window – ideal for subarray/substring problems
Depth-First Search (DFS) – for tree and graph traversal
Breadth-First Search (BFS) – used in shortest path and level order problems
Binary Search – for problems with sorted data or monotonic conditions
Merge Intervals – useful in scheduling and overlapping intervals
Dynamic Programming (DP) – for optimization and counting problems
Recursion & Backtracking – perfect for exhaustive search and decision trees
Monotonic Stack – for next greater/smaller element problems
Union-Find (DSU) – for detecting cycles and grouping connected components

Mastering these patterns allows you to recognize problem types quickly and apply efficient solutions, critical for success in FAANG interviews.

Q10. Why study coding patterns for interviews?

Studying coding patterns helps you avoid random practice and prepare more strategically. Instead of solving every problem from scratch, patterns teach you how to recognize the underlying structure of a problem and reuse proven techniques. This saves time, builds confidence, and dramatically improves your problem-solving skills.

Most interview problems are variations of core patterns.

By mastering them, you’ll be able to tackle new problems more quickly, reduce anxiety during live interviews, and demonstrate structured thinking, something interviewers love to see. In short, patterns are the shortcut to smarter and faster coding interview prep.

Go deeper: for the expanded version of this pattern-first approach, see the complete guide to all 42 coding interview patterns, which includes the tell that identifies each pattern from the problem statement, a printable cheat sheet, and free pattern-by-pattern deep dives.

Q11. How many LeetCode patterns are there?

There is no official count, because LeetCode does not publish one. This guide uses 20, which is the set that covers the overwhelming majority of interview questions without padding the list. Other lists quote 14, 15, or 23; the differences are mostly about whether closely related techniques are split apart or grouped together, not about the underlying ideas.

Q12. Are LeetCode patterns the same as design patterns or pattern matching?

No, and the three get confused often.

Design patterns are object-oriented structures such as Singleton, Factory, and Observer. They belong to object-oriented design and low level design rounds, not to the algorithmic patterns on this page. LeetCode does have a separate Design tag, with 134 problems like LRU Cache and Design Twitter, which asks you to build a data structure to a specification. That is a different skill again.

Pattern matching means string matching, regular expressions, and problems like Regular Expression Matching or Wildcard Matching. It is a problem topic, not a solving strategy.

The 20 on this page are coding patterns, also called DSA patterns: reusable strategies for recognizing and solving algorithm questions.

System Design Patterns: The Complete Guide (60+ Patterns Explained Simply)

Arslan Ahmad — Sun, 19 Jul 2026 06:41:18 +0000

Every system you admire is built from parts you can name. The feed that loads in 80 milliseconds, the checkout that survives a datacenter failure, the chatbot that answers from yesterday's documentation: each one is a composition of the same recurring solutions, applied in the right places. Those recurring solutions are system design patterns, and there are roughly sixty of them worth knowing.

This guide covers all of them. For each pattern you will get three things: the problem it solves, the core move it makes, and the price you pay for using it. By the end, you should be able to look at any architecture, or any interview prompt, and see the parts.

1. What Are System Design Patterns?

A system design pattern is a named, reusable solution to a problem that recurs when you build distributed systems. "Reads are overwhelming my database" is a recurring problem; primary-replica replication is its named solution. "A retry charged the customer twice" is a recurring problem; idempotency is its named solution.

Two clarifications before we start.

First, system design patterns are not the same as the classic "design patterns" from the Gang of Four book. Those are code-level patterns (Singleton, Observer, Factory) for organizing classes inside one program. System design patterns are architecture-level: they describe how databases, queues, caches, and services work together across many machines. In a system design interview, the interviewer means the architecture-level kind.

Second, a pattern is not a technology. Kafka is a product; the message queue and the append-only log are the patterns inside it. Redis is a product; cache-aside is the pattern you use it for. Learn the pattern and you can evaluate any product. Learn only the product and you are lost when the stack changes.

2. Why Patterns Beat Memorizing Architectures

There are thousands of possible system designs, and you cannot memorize them all. You do not need to. Architectures are sentences; patterns are the words. Once you own the vocabulary, "design Instagram" stops being a memory test and becomes a composition exercise.

Working with patterns is three habits:

Diagnosis. Recognize which problem you are actually looking at. Dashboards are green but one feature is starving: that is the bulkhead problem. Two teams' metrics disagree: that is the same question with two authors. Most of system design skill is matching symptoms to shapes.
Composition. Combine patterns, and handle the seams between them. Retries demand idempotency. Caches demand a stampede plan. Sagas demand designed compensations. The seams are where real engineering lives.
Pricing. Every pattern is a purchase. Sharding buys write scale and costs you cross-shard queries. Caching buys speed and costs you staleness. Saying the cost out loud, in the same breath as the pattern, is what separates senior answers from buzzword answers.

Keep those three habits in mind as you read the catalog below. Each entry is deliberately structured as diagnosis (the problem), composition material (the move), and price (the cost).

(I teach all sixty of these patterns in depth, each one through a real production incident, in my course System Design Patterns: From Fundamentals to Real Systems. This guide is the map; the course is the territory.)

3. The Complete List: 60+ System Design Patterns by Category

The patterns fall into ten categories. Use the list below to jump around, or read straight through: the order follows how problems actually arrive as a system grows.

Communication patterns (7)
Storage and replication patterns (6)
Caching patterns (5)
Reliability patterns (7)
Scaling patterns (5)
Consistency patterns (4)
API and edge patterns (9)
Operations and delivery patterns (5)
Data-intensive patterns (7)
AI-era patterns (7)

Communication Patterns: Moving Data Between Services

Request-Response. The default: a client asks, a server answers, someone waits. It is the right choice whenever a user is waiting for the answer. Its weakness is coupling: the caller's fate is tied to the callee's speed and health, which is why half the reliability patterns below exist.

Message Queue. Work that nobody needs to wait on goes into a queue, and workers process it at their own pace. Traffic spikes become backlog instead of outages. The price: delivery is at-least-once, so consumers must handle duplicates, and the queue's depth becomes a metric you must watch.

Publish-Subscribe. One event, many independent consumers. The order service announces "order placed" once; email, analytics, and inventory each react without knowing about each other. The price: your event schema becomes a public contract, and changing it becomes a negotiation.

Event-Driven Architecture. The pub-sub idea promoted to an architectural style: services react to facts instead of calling each other. You gain loose coupling and independent scaling. You pay in governance: who consumes what, and how a business flow is traced across five reacting services.

Webhooks. Events delivered across company boundaries as HTTP POSTs. The receiving discipline: verify the signature, save the raw event, respond in milliseconds, process later behind your own queue, and reconcile with a polling loop, because the worst webhook failure looks exactly like a quiet day.

Server-Sent Events (SSE). One HTTP response that never ends: the server pushes updates down it as they happen. It is why LLM chat apps show words one at a time. One direction only, and the browser handles reconnection for you. When the client needs to talk back continuously, you have outgrown it.

Bidirectional Streaming (WebSockets). A true two-way conversation on one connection: chat, collaborative editing, multiplayer games. The price is stateful, sticky connections and reconnection logic you now own. The rule: escalate to it on need, never on fashion.

Storage and Replication Patterns: Where Truth Lives

Primary-Replica Replication. One machine takes all writes and streams its change log to replicas that serve reads. Read capacity scales by adding copies, and a dead primary is replaced by promoting a replica. The price: replicas lag slightly, so a user can miss their own write, and replicas add zero write capacity.

Sharding. When writes or data size outgrow one machine, split the table's rows across machines by a shard key. The key is the whole game: it should appear in nearly every query, spread load evenly, and keep related rows together. The price: cross-shard queries, cross-shard transactions, and hot keys become your problems.

Consistent Hashing. The routing rule that lets a cluster change size gracefully. With naive modulo routing, adding a fifth shard moves 80% of all data. On the hash ring, it moves about 20%: only the slice the new server takes over. Virtual nodes keep the slices even and spread a dead server's load across everyone.

Write-Ahead Log (WAL). Before touching any data structure, the database appends one record describing the change to a log and forces it to disk. Only then does it say "saved." Crash recovery is replaying the log. This one mechanism also powers replication and point-in-time recovery, which makes the append-only log the most important structure in the database.

Event Sourcing. Store what happened, not what is. Every change is an immutable business event (OrderPlaced, OrderCancelled), and current state is derived by replaying them. Perfect audit trails and time travel, at the cost of projections for queries and event schemas that live forever. The default answer is no; the exception is ledger-shaped domains: money, orders, inventory.

CQRS. When reads and writes want different shapes, split the model: a lean, validated write model, and read models shaped for each question (a pre-joined table, a search index, an aggregates store), kept in sync from a change stream. Never sync them by writing to both from application code: dual writes drift silently.

Caching Patterns: Serving Data Fast

Cache-Aside. The default cache: the application checks the cache, loads from the database on a miss, and stores the result. Two numbers rule everything: the hit ratio and the staleness budget. Invalidation is your job, and the TTL is your safety net.

Read-Through. The cache itself loads misses from the database, so application code just reads. Cleaner call sites, at the cost of a smarter cache layer in your read path.

Write-Through. Writes go to the cache and the store together, so reads are always warm and never stale. The price: every write pays for both.

Write-Behind. Writes land in the cache and flush to the store later, in batches. Enormous write throughput, with a window where acknowledged data exists only in memory. Never for money.

Cache Stampede Prevention. When a popular key expires, a thousand requests can miss at once and crush the database together. The cures: let one request rebuild while others wait (single flight), add jitter to expiry times, and refresh hot keys before they expire.

Reliability Patterns: Surviving Failure

Timeout. No wait is allowed to be unbounded. Every network call gets a deadline, chosen from the callee's real latency profile. The subtlety: a timeout means "I stopped waiting," never "it did not happen." The work may have finished after you gave up, which is why idempotency exists.

Retry with Exponential Backoff. Transient failures deserve a second try, with increasing delays and randomness (jitter) so a thousand clients do not retry in lockstep and finish off a struggling server. Retries without backoff, jitter, and a budget are how outages get worse.

Idempotency. The same request processed twice must have the effect of once. The client generates a unique key per operation, and the server remembers keys it has seen. This is the pattern that makes retries safe, and the reason a double-clicked "Pay" button charges once.

Circuit Breaker. When a dependency keeps failing, stop calling it. Fail fast, give it time to recover, and probe occasionally to see if it is back. This turns a slow, cascading failure into a fast, contained one.

Bulkhead. Partition your resources so one workload cannot starve the rest. Separate connection pools, thread pools, or fleets per feature. The symptom it prevents: dashboards green overall while one feature quietly consumed every thread.

Dead Letter Queue. A message that fails repeatedly gets moved aside into a quarantine queue, so it stops blocking everything behind it. The DLQ needs an owner and an alert, or it becomes a place where problems go to be forgotten.

Graceful Degradation. Decide in advance what each feature does when its dependencies fail: serve stale data, show a smaller answer, or refuse. Availability features fail open; money and authorization fail closed. The worst answer is the one nobody designed: a blank error page.

Scaling Patterns: Growing Under Load

Vertical Scaling. A bigger machine. No new failure modes, no code changes, and it buys you time. It has a ceiling, and at the top of the catalog the prices climb steeply. Exhaust the simple win before taking on distributed problems.

Horizontal Scaling. Many identical, stateless copies behind a load balancer. The catch is the word stateless: sessions, counters, and files must move out of the server first, or each copy holds a different fraction of the truth.

Load Balancing. Spreading requests across those copies, informed by health checks and actual load. Draining connections before removing a server is the difference between a deploy and an incident.

Auto-Scaling. Capacity that follows demand: scheduled scaling for the load you can predict (most of it), reactive scaling for the surprise. Reaction takes minutes, so headroom is part of the design, and the maximum is a safety limit you set on purpose.

Connection Pooling. Opening a database connection is expensive; reuse a small pool of warm ones instead. The quiet trap: pool size multiplies across your fleet, and 50 servers with modest pools can exhaust a database's connection limit.

Consistency Patterns: Keeping Data Correct Across Machines

Two-Phase Commit (2PC). The coordinator asks all participants to prepare, then tells them all to commit: atomicity across machines. The price: everyone blocks if the coordinator dies at the wrong moment. It works inside one trust boundary; it does not cross companies. Often the best move is designing the transaction away entirely.

Saga. A long business transaction as a sequence of local steps, each with a designed compensation (undo) if a later step fails. Book the flight, book the hotel; if the hotel fails, unbook the flight. Order the irreversible steps last. This is how money moves between systems that share no database.

Quorum. Decisions by majority: with three or five copies, require agreement from more than half before an answer counts. Majorities prevent split brain, because two disagreeing majorities cannot exist. The price is latency, and a minority partition that goes read-only on purpose.

Vector Clocks. A way to track causality so the system can tell "this edit came after that one" apart from "these two edits happened concurrently and neither saw the other." Concurrent edits become explicit conflicts to resolve rather than silent overwrites.

API and Edge Patterns: The Front Door

Reverse Proxy. One front door for your servers: it terminates TLS, routes requests, and shields the fleet behind it. Nearly every pattern in this category is a specialized reverse proxy.

CDN. Copies of your content cached at the edge, near users. The two disciplines: getting invalidation right, and never letting private, per-user responses into a shared cache.

API Gateway. Cross-cutting policy enforced once: authentication, rate limits, routing to services. The discipline is staying thin. The moment business logic moves in, you have rebuilt the monolith in the doorway.

Backend for Frontend (BFF). A thin backend per client type (web, mobile) that composes reads into exactly the shape that client needs. Presentation composes reads; the domain services keep owning writes.

Rate Limiting. Protecting capacity by refusing excess politely: token buckets that allow bursts but cap sustained rates, tiered by customer. A 429 with a Retry-After header is a feature, not a failure.

Cursor-Based Pagination. Page through data by position ("after item X") instead of offset ("items 51-100"), so results stay stable while new data arrives. The price: no jumping to page seven.

API Versioning. Changing an API without breaking its clients: additive changes where possible, versioned contracts where not. Every field you publish is a promise someone will hold you to for years.

Sidecar. Cross-cutting concerns (TLS, retries, telemetry) packaged as a helper process that runs beside every service instance, in any language. The building block that makes the next pattern possible.

Service Mesh. Sidecars on every service plus a control plane: mutual TLS, retries, timeouts, and telemetry for all service-to-service traffic, without touching application code. A heavy platform. Adopt it when the service count and compliance needs clear the bar, not before.

Operations and Delivery Patterns: Shipping Without Breaking

Health Check Endpoint. The difference between "the process is running" (liveness) and "the process can do useful work" (readiness), exposed as endpoints that load balancers and deploys consult. Shallow checks lie; check the dependencies that matter.

Distributed Tracing. One request's story across every service it touched, stitched together by a trace ID. When the checkout is slow, the trace shows which of the nine hops ate the time. Instrumentation costs effort; debugging without it costs more.

Blue-Green Deployment. Two identical environments; switch traffic instantly, switch back instantly if something breaks. The catch everyone learns once: the database does not blue-green. Schema changes need the expand-contract discipline.

Canary Deployment. Release to a small slice first, judge it against the current version on real metrics, then widen. The judging is the pattern: a canary without honest verdict metrics is theater.

Feature Flags. Separate deploying code from releasing behavior. The code ships dark; the behavior turns on with a flag, per cohort, reversible in seconds. The debt: flags must be deleted after they win, or the codebase fills with dead switches.

Data-Intensive Patterns: Batch and Streaming

MapReduce. The batch shape: process a huge dataset by working on pieces in parallel where the data lives (map), regrouping by key (shuffle), and merging (reduce). You will never write raw MapReduce, and you will never escape its shape: it is the physics under every warehouse and Spark job.

Stream Processing. A job that runs forever, holding running counts keyed by the thing being watched, answering while the data is still arriving. Its hard ideas: event time versus arrival time, watermarks that decide when a window may close, and answers that may be amended when stragglers arrive.

Lambda and Kappa Architectures. Two answers to batch and streaming both computing the same numbers. Lambda runs both, with batch overwriting the stream's results on schedule. Kappa keeps one streaming codebase over a replayable log and re-runs history when logic changes. The rule either way: every metric gets exactly one definition of truth.

Change Data Capture (CDC). Tail the database's own write-ahead log and publish every committed change as an event. It cannot miss: bulk imports and manual fixes flow through the same log as app writes. This is how search indexes, caches, and warehouses stay in sync without fragile dual writes.

Exactly-Once Semantics. Counting things once despite crashes and retries. Delivery can never be exactly-once; the effect can be, by moving the processing state and the outputs together with the log position. Reserve the heavy machinery for numbers with auditors: billing, ledgers.

Backpressure. When a producer outruns a consumer, something must give: a bounded buffer absorbs bursts, a drop policy sheds what is worthless when stale, or the producer is slowed. The one wrong answer is the unbounded buffer, which schedules an out-of-memory crash instead of surfacing the mismatch.

Partitioned Consumption. Order per key, parallelism across keys: every event for a given customer lands in the same partition, each partition has exactly one consumer, so a refund can never be processed before its charge. The partition count is a ceiling chosen in advance, and one hot key can still make one partition burn.

AI-Era Patterns: LLM and ML Infrastructure

Nothing in the AI stack is architecturally new; every pattern here is one of the above operating under changed constants. But the changed constants matter enough that these seven deserve their own names.

Feature Store. Define each ML feature once, and let a platform compute it both offline for training and online for serving. This kills training/serving skew: the silent bug where a model learns from one definition of a number and gets served another.

Model Serving and Batching. At batch-of-one, a GPU serving an LLM runs at single-digit utilization, because each token step streams the whole model's weights to do almost no math. Continuous batching lets dozens of requests share each weight-pass, multiplying throughput 20-30x. It is the difference between a viable AI feature and an absurd bill.

GPU Auto-Scaling. Web autoscaling with both dials at 100x: idle GPUs cost a hundred times more, and cold starts take minutes, not seconds. The answers: scale on queue depth (never CPU), keep warm pools as priced insurance, pre-warm on the calendar, and fall back to a smaller model when capacity gaps hit.

LLM Gateway. One internal door for all model traffic: it holds the provider keys, meters every token against budgets with hard caps, routes logical model names to physical providers, and runs the failover ladder when a provider browns out. The API gateway pattern, pointed outward.

Semantic Caching. Forty percent of user questions are rephrasings of known questions, but exact-match caching catches almost none of them. Key the cache by meaning instead: embed the query and match by similarity, with a conservative threshold, because a false hit serves a confidently wrong answer.

Vector Database Sharding. Similarity search breaks normal sharding's best rule: a nearest-neighbor query has no shard key, so the default is asking every shard and merging. The escape: when every query is tenant-scoped, the tenant filter becomes the shard key and single-shard routing returns.

RAG Pipeline. Knowledge in model weights has no update path, no citations, and no access control. Retrieval-Augmented Generation fixes all three: keep documents in an index that updates in seconds, retrieve only what the asker is permitted to read, and require the model to answer from the retrieved text with citations. The model reasons; the index remembers.

4. How Patterns Compose: A News Feed in Ten Patterns

A pattern list becomes useful when you see composition. Take the classic prompt: design a social feed. Watch the patterns snap together.

Reads outnumber writes about 50 to 1, so the feed is a read-serving problem. Precompute each user's feed at write time and serve it like a cache: this is CQRS, with the feed as a read model. Posting fans out through a message queue with partitioned consumption, fed reliably by an outbox (CDC) so a committed post always reaches the pipeline. The feed store is a sharded, consistent-hashed cluster of lists, evicted and rebuilt like any cache. Celebrities with 50 million followers would break write-time fan-out, so their posts merge at read time from a hot cache with stampede prevention. Fan-out workers auto-scale on backlog age. Appends are idempotent so at-least-once delivery cannot duplicate a post. When parts fail, the feed degrades gracefully: slightly stale beats blank.

Ten-plus patterns, one design, and every choice justified by a number or a failure mode. That is what interviewers mean when they say a candidate "thinks in systems." It is also the skill this entire catalog exists to build: not knowing sixty definitions, but composing the right eight of them under pressure.

5. How to Learn These Patterns Properly

Reading a list is recognition. Interviews and production require recall and application. Three suggestions:

Learn each pattern through its failure story. Every pattern above exists because something broke at 2 AM. "Cache stampede prevention" is forgettable; "a thousand requests missed the same expired key at once and crushed the database" is not. Attach each pattern to its incident.
Always learn the price and the "when not." A pattern you cannot argue against is a pattern you do not understand. Sharding from day one, CQRS on a settings page, and event sourcing everywhere are the classic ways to pay real complexity for imaginary scale.
Practice composition on full designs. Run the classic prompts (a feed, a ride-sharing dispatch, a payment platform) and force yourself to name every pattern you use and what it costs, out loud.

This is exactly how my course, System Design Patterns: From Fundamentals to Real Systems, is built. All sixty-plus patterns above get a full lesson: a real production incident, the naive fixes and why they fail, a walkthrough with real numbers, the trade-offs, when NOT to use it, and a 30-second interview answer you can say under pressure. The course ends with four complete interview walkthroughs (a news feed, ride-sharing dispatch, a payment platform, and an AI copilot) where you watch the sixty patterns compose into real systems.

6. Frequently Asked Questions

What are system design patterns?
System design patterns are named, reusable solutions to problems that recur in distributed systems: scaling reads, surviving failures, keeping data consistent across machines, and moving data between services. They are architecture-level building blocks, used to design systems like feeds, payment platforms, and chat applications.

How many system design patterns are there?
Around sixty patterns cover essentially everything asked in interviews and used in production, spanning communication, storage, caching, reliability, scaling, consistency, APIs, operations, data engineering, and AI infrastructure. This guide lists all of them by category.

Are system design patterns the same as design patterns?
No. Classic design patterns (from the Gang of Four book) organize code inside one program: Singleton, Observer, Factory. System design patterns organize infrastructure across many machines: sharding, caching, circuit breakers, sagas. In system design interviews, the interviewer means the architecture-level kind.

Which system design patterns matter most for interviews?
Eight patterns appear in the overwhelming majority of interview questions: cache-aside, sharding, message queues, circuit breakers, idempotency, sagas, CQRS, and rate limiting. Learn those deeply first, then broaden. The highest-scoring skill is not naming patterns but stating each one's cost as you use it.

Do AI systems need new system design patterns?
Mostly no, and that is good news. The LLM gateway is the API gateway pattern pointed outward, semantic caching is cache-aside with similarity instead of equality, and GPU autoscaling is standard autoscaling with far harsher constants. An engineer who knows the classic sixty walks into AI infrastructure already knowing the building.

Arslan Ahmad is the author of Grokking the System Design Interview and founder of DesignGurus.io. His new course, System Design Patterns: From Fundamentals to Real Systems, teaches all sixty-plus patterns in this guide through real production incidents.

Originally published on DesignGurus.io.

I've taught system design to hundreds of engineers. Here's where I tell them all to start.

Arslan Ahmad — Sat, 04 Jul 2026 03:54:11 +0000

Somewhere around the hundredth engineer I coached, I noticed something. Nobody was struggling with system design because it was too hard. They were struggling because they started in the wrong place.

The pattern was always the same. A smart engineer with two or three years of experience decides it's time to learn system design. They search YouTube, land on "Design Instagram in 45 minutes," and watch someone draw fifteen boxes connected by arrows. They understand maybe four of the boxes. They finish the video feeling like they learned something, try to design anything on their own, and produce a server, a database, and silence.

Then they conclude system design is a genius-only club, and they either give up or start memorizing diagrams.

If that's you, nothing is wrong with you. You just entered the building through the roof.

The lie that keeps beginners stuck

Here's what I wish someone had told me when I was coming up through Microsoft and Facebook: system design is not as big as it looks.

It looks infinite because content about it has no agreed-upon sequence. Every blog post assumes you already know whatever the last blog post covered. Every video introduces five terms it never defines. There's no "chapter one" anywhere on the front page of Google.

But strip the noise away and the field that matters for interviews and for real engineering work reduces to roughly 12 recurring patterns, combined in different ways. Netflix is not magic. Uber is not magic. They're the same dozen ideas arranged for different constraints.

You cannot see that from the roof. You can only see it from the foundation.

The 5 concepts I make everyone learn first

When someone asks me where to start, I give them the same assignment every time: learn these five things, and don't touch a case study until you can explain each one to a non-engineer.

1. The client-server model. A client asks, a server answers. Every system you will ever design begins with "the client sends a request to our API server." If this sentence isn't boring and obvious to you yet, everything downstream will feel like fog.

2. Databases. Where data lives when the power goes out. You need exactly one distinction at this stage: SQL databases are structured and relational, NoSQL databases are flexible and easier to scale horizontally. That's it. Do not fall down the "PostgreSQL vs Cassandra vs DynamoDB" rabbit hole in week one.

3. APIs. The contracts that let pieces of software talk to each other without knowing each other's internals. In a design discussion, APIs are the seams of your architecture: where you cut, and where things can change independently.

4. Load balancing. One server can't handle a million users, so you run fifty servers, and something has to decide which request goes where. That something is a load balancer, and it appears in every design answer you will ever give. Think of a restaurant hostess distributing guests across tables so no waiter drowns.

5. Caching. Databases are slow compared to memory. If a million people request the same homepage feed, computing it a million times is waste. Store the answer once in RAM, serve it a million times in microseconds. Most of "making systems fast" is some version of this idea.

That's the whole first week. Five concepts. Engineers are usually suspicious of how small this list is, and then a month later they tell me it's the reason the rest finally made sense.

Why this order beats the "just watch case studies" approach

Case studies are the best part of learning system design. They're also nearly worthless if you do them first.

When you watch "Design a URL Shortener" without knowing the building blocks, you're memorizing a specific answer. When the constraints change ("what if reads are 100x writes?"), the memorized answer shatters, because you never knew why the cache was there in the first place.

When you do the same case study after learning the blocks, you're doing something completely different: you're practicing selection. You know what a cache does, so the question becomes "does this system need one, and where?" That's the actual skill interviewers grade. It's also the actual skill your job requires.

Same video. Same diagram. Entirely different learning outcome, purely based on what you knew walking in.

The sequence that works

After the first five concepts, the path I give people looks like this:

Learn the next 7 building blocks: sharding, replication, consistency models, message queues, CDNs, indexing, and back-of-the-envelope estimation. Same rule as before: understand what problem each one solves, skip the depth.
Learn a framework. Requirements, estimation, API, data model, high-level architecture, deep dives, trade-offs. In that order, every time. A framework turns "design Twitter" from a blank-whiteboard panic into a sequence of small, answerable questions.
Now do case studies. Start with the URL shortener, then a chat app, then a news feed. Attempt each one yourself, out loud, for 45 minutes before you look at any solution. The gap between your answer and the reference answer is your personalized curriculum.
Practice out loud, with a human if possible. System design interviews are conversations, not exams. I've seen engineers who knew plenty fail because the first time they'd ever articulated a trade-off verbally was in the actual interview.

Spread over eight weeks at an hour or two a day, this takes someone from "what's a load balancer?" to holding a coherent 45-minute design conversation. I've written the full week-by-week version, with links for every concept, in my system design roadmap for beginners if you want the detailed plan.

The three failure modes to watch for

After enough repetitions, I can predict how someone will get stuck before they start:

The memorizer collects architecture diagrams like trading cards and freezes the moment an interviewer changes one constraint. Fix: for every component in a design, force yourself to answer "what breaks if I remove this?"
The roof-jumper goes straight to "Design WhatsApp" content and drowns in jargon. Fix: the five concepts above, first, no exceptions.
The passive consumer watches 30 hours of videos, feels fluent, and can't produce a design from a blank page. Fix: never end a study session without explaining what you learned out loud, to a rubber duck if necessary.

All three failure modes share a root cause: consuming content feels like progress, and applying concepts feels like struggle. The struggle is the part that works.

Start smaller than feels reasonable

If you take one thing from this post, make it this: the engineers who get good at system design are not the ones who were smarter. They're the ones who started with embarrassingly basic material and actually practiced it, while everyone else skipped ahead and silently churned.

Client-server. Databases. APIs. Load balancing. Caching. Learn those five this week, explain each one out loud to someone patient, and you'll be ahead of most people grinding case study videos.

And when you're ready for the structured version of the whole journey, the full 8-week roadmap is free, and my System Design Fundamentals course covers the building-blocks phase in one sequenced curriculum if you'd rather not assemble it yourself.

You don't need to be a distributed-systems wizard to start. You need chapter one. Now you have it.

What tripped you up when you started learning system design? I read every comment.

System Design Fundamentals: The 10 Building Blocks to Learn First

Arslan Ahmad — Thu, 02 Jul 2026 12:57:22 +0000

Most people learn system design backwards. They start by reading how Netflix or Uber is built, memorize the finished architecture, and then freeze the moment they're asked to design something slightly different.

The fix is to learn the parts before the whole. Every large system is assembled from a small set of reusable building blocks. Once you understand each block on its own, designing a full system becomes an exercise in choosing which blocks to combine and why. This post covers the 10 to learn first, in a sensible order, so you have the vocabulary before you attempt your first design. If you want to see where these fit in the bigger picture, here's a structured roadmap to learn system design at your level.

How to study each block: solves, costs, when

Do not just memorize what each component is. For every block, learn three things:

What it solves. The specific problem that makes you reach for it.
What it costs. The new problem it introduces (every block adds one).
When to use it. The signal in a design that says "now I need this."

That third habit is what separates people who can design real systems from people who can only recite them. Keep those three columns in mind as you read.

1. Load Balancer

What it is: A traffic cop that sits in front of multiple servers and spreads incoming requests across them.

What it solves: A single server can only handle so much. A load balancer lets you run many identical servers and distribute load, which gives you both scale and redundancy (if one server dies, traffic routes to the others).

What it costs: It becomes a component you have to make highly available itself, and it forces your servers to be stateless (or you have to deal with sticky sessions).

When to reach for it: The moment you say "one server isn't enough" or "what happens if this server goes down."

2. Caching

What it is: A fast, temporary store for data you access often, sitting between your app and a slower source (like a database).

What it solves: Latency and load. Reading from memory is orders of magnitude faster than hitting a database, and it takes pressure off your data store.

What it costs: Staleness. The cached copy can drift from the source of truth, so now you own cache invalidation, famously one of the hard problems in computing.

When to reach for it: Read-heavy workloads, or any time the same data is requested over and over.

3. Database Replication

What it is: Keeping copies of your database on multiple machines, usually one primary (writes) and several replicas (reads).

What it solves: Read scalability and availability. You can spread reads across replicas, and if the primary fails, a replica can take over.

What it costs: Replication lag. Replicas can be slightly behind the primary, so a user might not immediately see their own write. That's the consistency trade-off.

When to reach for it: When reads vastly outnumber writes, or when you can't afford to lose the database if one machine fails.

4. Database Sharding

What it is: Splitting one large database into smaller pieces (shards), each holding a subset of the data, spread across machines.

What it solves: Write scalability and storage limits. When the data or write volume outgrows a single machine, sharding partitions the load.

What it costs: A large jump in complexity. Cross-shard queries get hard, and choosing a bad shard key creates "hot" shards that defeat the whole purpose.

When to reach for it: When a single database server can no longer hold your data or absorb your writes, and only then. Replication first, sharding later.

5. Message Queue

What it is: A buffer that holds messages so one part of your system can hand off work to another without waiting.

What it solves: Decoupling and load smoothing. Producers and consumers work at their own pace, and traffic spikes get absorbed by the queue instead of crushing a service.

What it costs: Added latency (work is now asynchronous) and new failure modes (duplicate messages, ordering, what happens when the queue backs up).

When to reach for it: When work can happen later rather than instantly (sending emails, processing uploads, generating notifications).

6. Consistent Hashing

What it is: A clever way to distribute data across a changing set of servers so that adding or removing a server only moves a small fraction of the data.

What it solves: The rehashing problem. With naive hashing, adding one server reshuffles almost everything. Consistent hashing keeps that disruption minimal.

What it costs: Conceptual complexity, and the need for tricks like virtual nodes to keep the distribution even.

When to reach for it: Any time you're distributing data or requests across a cluster whose size changes (caches, sharded stores). I broke this one down step by step in consistent hashing in a system design interview.

7. CDN (Content Delivery Network)

What it is: A globally distributed network of servers that cache your static content close to users.

What it solves: Latency for a global audience. Serving an image or video from a city near the user is far faster than from one origin server across the world.

What it costs: Cost, plus cache invalidation again (pushing updates to edge locations takes time).

When to reach for it: When you serve static assets (images, video, JS/CSS) to users spread across regions.

8. Rate Limiter

What it is: A guard that caps how many requests a client can make in a given window.

What it solves: Abuse and overload. It protects your system from being overwhelmed, whether by malicious traffic, buggy clients, or a single user hammering an endpoint.

What it costs: You have to store and check counters fast (often in a cache), and you have to decide what to do with rejected requests.

When to reach for it: Any public API, login endpoint, or any resource you need to protect from spikes and abuse.

9. Database Indexing

What it is: A data structure that lets the database find rows without scanning the entire table.

What it solves: Slow reads. An index turns a full-table scan into a fast lookup, dramatically speeding up queries.

What it costs: Slower writes (every write must update the index) and extra storage. Over-indexing is a real mistake.

When to reach for it: When a query is slow and it filters or sorts on a specific column. This is often the cheapest performance win available.

10. Data Modeling

What it is: Deciding how your data is structured and stored: relational tables versus documents, how entities relate, what you optimize for.

What it solves: Almost everything downstream. The right model makes your common queries easy and fast; the wrong one makes every later decision harder.

What it costs: Time and foresight up front, and the reality that changing the model later is painful.

When to reach for it: First. Before you pick components, understand your data and its access patterns. This is the foundation the other nine blocks sit on.

How the blocks combine

Here's the payoff. Take a simple service and watch the blocks appear as constraints arrive:

Start with one server and a database (data modeling).
Traffic grows, so you add more servers behind a load balancer.
Reads are slow, so you add a cache and some indexes.
Reads still outpace one database, so you add replication.
The data outgrows one machine, so you shard it (using consistent hashing).
Some work doesn't need to be instant, so you offload it to a message queue.
Users are global, so static assets move to a CDN.
The public API needs protection, so you add a rate limiter.

Every block entered the design because a specific problem demanded it, not because a checklist said so. That's exactly how you should reason in a real design.

What to learn next

Learn these 10 in roughly the order above (data modeling first, sharding and consistent hashing last, since they're the most advanced). Write your own three-line summary for each: solves, costs, when. Then start composing them into full systems.

If you're brand new and even the prerequisites feel shaky, start with learning system design from scratch. And when you're ready to see how deep each block should go at your career stage, follow the full path in this roadmap by career level.

Master the parts, and the whole stops being intimidating. Every "complex" architecture you've ever admired is just these blocks, combined to answer specific constraints.

How to Learn System Design From Scratch (With No Distributed Systems Experience)

Arslan Ahmad — Tue, 30 Jun 2026 21:24:53 +0000

If you have ever opened a system design article, seen a diagram with twelve boxes, three databases, a message queue, and the words "eventually consistent," and quietly closed the tab, this post is for you.

There is a myth that you need years of experience running large systems before you can learn system design. You don't. Plenty of engineers learn it before they have ever deployed anything bigger than a side project. What you actually need is the right starting point and a way to build intuition without access to production-scale traffic. That is exactly what this guide gives you.

"But I've never built anything at scale"

Good news: neither had most people the first time they learned this. System design is not a memory test about how Uber works. It is a thinking skill: given a vague problem and some constraints, make a sequence of reasonable trade-offs and explain them clearly.

That skill does not require having operated a system serving millions of users. It requires understanding what the moving parts do and practicing the reasoning. The experience helps later, but it is not the price of entry. So drop the idea that you are "not ready." You are ready to start today.

The honest minimum prerequisites

You do not need much, but you do need these four things. If any feels shaky, spend a few days here first; it will save you weeks of confusion later.

What happens when you load a web page. Client sends a request, DNS resolves a name to an address, a server responds. If you can sketch that, you're fine.
The two kinds of databases. Relational (tables, rows, SQL) versus non-relational (documents, key-value). You don't need to be an expert, just know they exist and roughly when each fits.
What an index is. A way to find data fast without scanning everything. That one sentence is enough to begin.
Basic estimation. If something gets a million requests a day, roughly how many is that per second? (About 12, for the record.) The ability to do rough math out loud matters more than precision.

Notice what is not on this list: Kubernetes, Kafka, distributed consensus, the CAP theorem. Beginners reach for those far too early. You will learn them when a problem actually demands them.

The mindset shift that unlocks everything

Beginners try to learn system design by collecting answers: how is Instagram's feed built, how does WhatsApp deliver messages, how does YouTube store video. They memorize a dozen "reference architectures" and feel productive.

Then they get asked to design something slightly different, and nothing transfers.

The fix is to learn reasoning, not answers. For every component you study, learn two things: what problem it solves and what new problem it creates. A cache makes reads fast (solves latency) but can serve stale data (creates a consistency problem). A queue smooths traffic spikes (solves load) but adds delay and complexity (creates new failure modes). Once you think in those trade-offs, you can design things you have never seen before. That is the whole game.

Your first design: build it, don't read it

Reading designs builds recognition. Building one builds competence. So for your very first system, pick something small enough to finish in one sitting and deep enough to teach the core ideas. The classic choice is a URL shortener (think bit.ly), and it is the perfect no-experience starter.

Here is the trick that makes it work: start with the dumbest possible version, then break it on purpose.

Version 1, the naive design. One server, one database. A user submits a long URL, you generate a short code, store the pair, and redirect on lookup. That's it. It works for ten users. Congratulations, you have designed a system.
Now add a constraint. "It needs to handle 100 million redirects a day." Suddenly your single database read on every redirect is a problem. What solves slow reads? A cache. So you add one. (And now you own the staleness trade-off you just learned about.)
Add another. "Short codes must never collide." Now you have to think about how codes are generated: random with a uniqueness check, or a counter, or a hash. Each has trade-offs.
Add one more. "One database server can't hold all the data." Now you need to split it across machines, which is your gentle introduction to sharding.

See what happened? Each constraint forced exactly one new idea, and you learned that idea because you needed it, not because a textbook listed it. That is how real systems grow, and it is how you should learn. For a full worked version of this exact problem, see my walkthrough of designing a URL shortening service.

How to build intuition without a production system

You can't experiment on real traffic yet, so build intuition these three ways instead:

Read with a question, not a highlighter. When you read how a real system works, stop at each component and ask "what would break if they removed this?" If you can answer, you understand it. If you can't, that's the part to study next.
Build small versions for real. A rate limiter is a weekend project. A simple key-value cache is a weekend project. A basic message queue is a weekend project. Building a tiny version teaches you more than reading about the big version.
Reason about apps you already use. Every time you use an app, ask one design question. Why does the like count sometimes look slightly off? (Probably caching.) Why can you send a message offline and it sends later? (Probably a queue.) You are surrounded by free case studies.

A 4-week beginner ramp

If you want a path instead of a pile of topics, here is a realistic one. Forty focused minutes a day beats a frantic weekend.

Week 1: Foundations. One building block per day: load balancer, cache, database replication, sharding, message queue. For each, write three sentences (what it solves, what it costs, when to use it).

Week 2: Your first systems. Design the URL shortener end to end, evolving it under constraints as shown above. Then do a second small one (a pastebin or a basic image host) the same way.

Week 3: A bigger system. Attempt a news feed or a chat app. You will get stuck. That is the point; the stuck moments tell you exactly what to study next.

Week 4: Practice out loud. Re-design two earlier systems from a blank page, talking through every decision as if explaining to someone. If you can't explain a choice, you haven't learned it yet.

After four weeks you won't be a senior architect, but you will no longer be a beginner, and you will know how to keep going.

Beginner mistakes to skip

Starting with the "impressive" architecture. Microservices and Kafka on day one is a red flag, not a flex. Start simple, justify every addition.
Memorizing reference designs. You will be asked something off-script. Learn the reasoning.
Studying components you never use. You don't need to deeply understand distributed consensus to design a URL shortener. Learn things when a problem demands them.
Practicing silently. System design is a communication skill. If you only think it through in your head, you are training the wrong muscle.
Skipping the math. "It scales" is not an answer. Rough numbers are what justify your choices.

FAQ

Do I really not need experience with big systems?
Correct. Experience accelerates intuition later, but the building-block-then-composition path works fine without it. Many engineers learn system design before ever operating one at scale.

How long until I'm "good"?
For a solid beginner foundation, about 4 weeks of consistent practice. Genuine mastery is a multi-year, on-the-job journey, and that's normal.

Is this only useful for interviews?
No. The same skill (making and defending trade-offs) is exactly what you do when designing real systems at work. Interview prep is just a concentrated version of it.

Where to go next

Once the fundamentals click, the natural next step is to study what depth is expected at each stage of your career. When you're ready, here's where to start learning system design with a level-by-level path, and a companion roadmap that lays out the same journey as a roadmap by career level. And when the interview itself is on the calendar, The Complete System Design Interview Guide for 2027 covers the framework, the scoring signals, and a full worked example.

The engineers who get good at this are not the ones who read the most. They are the ones who designed the most systems out loud, starting with the dumbest possible version and letting the constraints teach them. You can start that today, with zero experience. Pick the URL shortener, build the naive version, then break it.

How to Learn System Design: A Roadmap by Career Level

Arslan Ahmad — Mon, 29 Jun 2026 10:53:47 +0000

Most engineers do not struggle with system design because they lack intelligence. They struggle because the topic has no obvious starting point and no obvious finish line. Coding has LeetCode. System design has... a thousand blog posts, a few thick books, and a lot of hand-waving about "scalability."

This guide fixes the starting-point problem. It lays out how to learn system design as a sequence: what to learn first, what to learn next, and what "good enough" looks like at each stage of your career. If you want the fuller, continuously updated version, Design Gurus maintains a structured guide on how to learn system design organized by career level. This article gives you the condensed roadmap.

Learning system design is not memorizing architectures

The most common mistake is treating system design like trivia: memorize how Twitter's feed works, how Uber matches drivers, how a URL shortener generates keys. You can recite all of it and still freeze when asked to design something you have not seen.

System design is a skill, not a fact set. The skill is this: given a vague problem and real constraints, make a sequence of defensible trade-offs and communicate them clearly. Everything below is built to train that skill, not to pad your memory.

Prerequisites: what you need before you start

You do not need to be a senior engineer to begin, but you do need a few fundamentals. If any of these are shaky, shore them up first:

Networking basics: what happens when a client calls a server (DNS, TCP, HTTP, status codes).
Databases: the difference between a relational and a non-relational store, what an index is, what a transaction is.
Concurrency basics: what a race condition is, why shared state is hard.
Back-of-the-envelope math: powers of two, latency numbers, how to estimate QPS and storage.

If you can comfortably explain those at a whiteboard, you are ready.

The three-phase learning path

Every effective learning sequence I have seen follows the same arc. Skipping a phase is the fastest way to plateau.

Phase 1: Foundations (learn the building blocks in isolation)

Before you compose a system, you need to understand its parts well enough to know when each one applies. Learn these one at a time, and for each, learn what problem it solves and what it costs:

Load balancers
Caching (and cache invalidation strategies)
Database replication and sharding
Message queues and asynchronous processing
Consistent hashing
CDNs
Rate limiting
Indexing and data modeling

Do not move on until you can answer, for each: "When would I add this, and what new problem does adding it create?" Caching, for example, solves latency but creates staleness. That trade-off framing is the entire game.

For a deeper breakdown of each block (what it solves, what it costs, and when to reach for it), see the 10 system design building blocks to learn first.

Phase 2: Composition (assemble blocks into systems)

Now combine the blocks. Take a classic prompt and build it up incrementally. A good first target is a URL shortener: simple enough to finish, deep enough to touch key generation, storage, caching, and read/write skew.

The key habit here is to start simple and evolve under pressure. Begin with the naive single-server design, then introduce a constraint ("now it serves 100M requests a day") and react to it. Each constraint should force exactly one architectural change. That is how real systems grow, and it is how interviewers expect you to think.

Work through 8 to 12 canonical systems this way: a news feed, a chat app, a rate limiter, a typeahead service, a video platform, a ride-sharing matcher, a notification system. The repetition builds pattern recognition.

Phase 3: Practice (perform under realistic conditions)

Reading designs builds recognition. Producing them under a clock builds competence. In this phase you design out loud, on a timer, ideally with someone pushing back. The full system design learning roadmap by level breaks down how much practice each career stage actually needs, but the principle is constant: you only own a concept once you can explain it without notes.

The most realistic version of this is a full mock interview. This guide to system design mock interviews explains how a 45-minute mock is structured and scored, and compares solo, peer, expert, and AI practice options.

What to learn at each career level

"Learn system design" means different things depending on where you are. Calibrate your depth to your target level so you neither under-prepare nor waste months on staff-level concerns you will not be asked about.

Junior (L3)

The bar is fundamentals, not novel architecture. You should be able to design a basic CRUD service, expose a clean API, pick a reasonable database, and explain a single caching layer. Depth of building blocks matters more than breadth of systems.

Mid-level (L4)

Now you compose. You should design a complete system end to end, identify bottlenecks, and reason about scaling reads vs writes. You are expected to know when to shard, when to add a queue, and what consistency model fits the use case.

Senior (L5)

The focus shifts to trade-offs and justification. Two valid designs exist for almost every problem; your job is to pick one and defend it against the alternative. Expect deep dives: "Walk me through exactly how you keep the cache consistent here." Non-functional requirements (availability, latency targets, cost) drive your decisions.

Staff and above (L6+)

The scope widens beyond one system to platforms and organizations. You reason about evolvability, migration paths, failure domains, multi-region strategy, and the human cost of operating what you propose. The question is less "does it work" and more "will this still be the right call in three years."

A concrete weekly cadence

If you want a plan rather than a pile of topics, here is a sustainable rhythm:

Weeks 1 to 2: One building block per day from Phase 1. Write a three-sentence summary of each (problem it solves, cost it adds, when to reach for it).
Weeks 3 to 5: One full system every two days from Phase 2, evolving each from naive to scaled.
Weeks 6 onward: Timed mock designs from Phase 3, two per week, reviewed honestly afterward.

Consistency beats intensity. Forty focused minutes a day will outperform a frantic weekend cram every time.

Common mistakes that stall people

Jumping to the "impressive" architecture immediately. Start with the simplest thing that works, then justify each addition. Leading with Kafka and microservices for a problem that needs neither is a red flag.
Memorizing reference designs. You will be asked something off-script. Learn the reasoning, not the diagram.
Ignoring requirements. Spending zero time clarifying scope and then designing the wrong system is the most common failure mode, and the most avoidable.
Practicing silently. System design is a communication exercise. If you only practice in your head, you are training the wrong muscle.
Skipping the math. "It scales" is not an answer. Numbers (QPS, storage, bandwidth) are what justify your choices.

FAQ

How long does it take to learn system design?
For interview readiness, most engineers need 4 to 8 weeks of consistent practice on top of solid fundamentals. Genuine mastery is a multi-year, on-the-job process.

Is system design only for interviews?
No. The same skill (making and defending architectural trade-offs) is exactly what you do when designing real systems at work. Interview prep is just a focused version of it.

Do I need real distributed-systems experience first?
No. Experience helps, but the building-block-then-composition path works without it. Plenty of engineers learn this before they have ever operated a large system. If you're starting from zero, I wrote a companion guide on learning system design from scratch with no experience.

Where to go next

Pick your level, start at Phase 1, and do not skip ahead. If you want the structured, regularly updated version of this path with level-specific checklists, work through Design Gurus' guide on how to learn system design. And when you are ready to drill full problems with worked solutions, Grokking the System Design Interview walks through the canonical systems end to end.

The engineers who get good at this are not the ones who read the most. They are the ones who designed the most systems out loud. Start today, start simple, and let the constraints teach you.

Must-do system design questions.

Arslan Ahmad — Thu, 25 Jun 2026 11:39:21 +0000

Arslan Ahmad

Apr 12

64 System Design Interview Questions, Ranked From Easiest to Hardest

#systemdesign #softwaredevelopment #interview #ai

19 min read

AI System Design Interview Questions: ChatGPT, RAG, LLM Inference, and Agents

Arslan Ahmad — Thu, 25 Jun 2026 11:38:22 +0000

System design interviews are changing.

Traditional questions such as “Design Twitter,” “Design Uber,” and “Design YouTube” are still important. They test whether you understand databases, caching, partitioning, replication, messaging, and high availability.

But engineers working on modern platforms now encounter a different category of problem:

Design a ChatGPT-like conversational assistant.
Design a retrieval-augmented generation system.
Design an LLM inference platform.
Design an AI agent that can call external tools.
Design an enterprise AI assistant for private documents.
Design an evaluation platform for generative AI applications.

These questions still require classical distributed-systems knowledge. An AI product needs APIs, queues, storage, authentication, observability, rate limiting, and reliable deployment.

The difference is that it also introduces expensive accelerators, probabilistic output, long-running requests, model routing, vector retrieval, prompt construction, safety controls, and quality evaluation.

This guide explains the most important AI system design interview questions and what a strong candidate should discuss for each.

For a broader preparation roadmap covering traditional and modern problems, see 64 System Design Interview Questions, Ranked From Easiest to Hardest.

Why AI System Design Is Different

A conventional service usually transforms an input into a deterministic output.

If a user requests order number 123, the service should retrieve order 123. Two identical requests should usually return the same underlying information.

Generative AI systems behave differently.

A model may produce different responses to the same prompt. A response can be grammatically convincing while being factually wrong. Latency depends on the number of generated tokens. Serving capacity is constrained by accelerator memory, not merely CPU utilization. Product quality may depend on prompts, retrieved context, model versions, safety filters, and external tools.

This creates several new design dimensions.

1. Quality is part of the architecture

Traditional systems are often measured using availability, latency, throughput, and error rate.

AI systems need those metrics, but they also need measures such as:

Answer correctness
Relevance
Groundedness
Retrieval quality
Hallucination rate
Tool-use success
Safety-policy compliance
User satisfaction

A system that returns a response in 200 milliseconds is not useful if that response is wrong.

2. Requests are computationally expensive

An ordinary API server may process thousands of lightweight requests per second.

An LLM request can occupy expensive GPU memory while processing a long prompt and generating hundreds of tokens. The architecture must therefore optimize batching, memory utilization, model placement, and request scheduling.

3. Latency is experienced as a stream

Users do not normally wait for an entire answer before seeing anything. Tokens are streamed as they are generated.

This introduces at least two important latency measurements:

Time to first token: How quickly generation begins.
Inter-token latency: How smoothly subsequent tokens arrive.

A system may have acceptable total latency but still feel slow if the first token takes too long.

4. Data enters the system in several ways

An AI application may depend on:

Model-training data
User prompts
Conversation history
Retrieved documents
Tool results
Feedback
Evaluation datasets
Safety policies

Each data type has distinct requirements for retention, privacy, freshness, and consistency.

5. Failure is not always binary

A traditional request may succeed or fail.

An AI request can technically succeed but produce a low-quality answer, retrieve the wrong documents, call the wrong tool, exceed a cost budget, or violate a safety rule.

The architecture must detect and respond to these softer failure modes.

A Framework for Answering Any AI System Design Question

Before considering individual questions, use a consistent interview structure.

Step 1: Clarify the product

Ask what the system is expected to do.

For example:

Is the assistant general-purpose or domain-specific?
Does it need private enterprise data?
Can it take actions or only provide answers?
Does it support text only, or also images, audio, and files?
Are responses expected in real time?
Does the system need citations?
Which decisions require human approval?

Without this clarification, “Design an AI assistant” is too broad.

Step 2: Define scale and service-level objectives

Estimate:

Daily and peak requests
Average prompt size
Average output length
Concurrent users
Required time to first token
Model size
GPU-memory requirements
Availability target
Cost per request

AI systems are often constrained by cost as much as by technical capacity.

Step 3: Separate the application layer from the model layer

The application layer may include:

Authentication
Billing
Conversation history
File management
User preferences
Rate limiting
Analytics

The AI layer may include:

Prompt construction
Retrieval
Model routing
Inference scheduling
Safety checks
Tool execution
Evaluation

Keeping these concerns separate makes the design easier to explain and evolve.

Step 4: Trace the complete request path

Describe what happens from the moment a user submits a prompt until the final result is displayed.

A typical path may be:

Authenticate the request.
Enforce quotas.
Load conversation state.
Retrieve relevant context.
Construct the model prompt.
Run input-safety checks.
Select a model.
Schedule inference.
Stream tokens.
Run output-safety checks.
Store the response.
Record metrics and feedback.

Step 5: Discuss failure, quality, and cost

A strong answer should explain:

What happens when the primary model is overloaded?
What happens when retrieval returns no useful documents?
How are duplicate tool calls prevented?
How does the system degrade gracefully?
How are model changes evaluated?
How is tenant data isolated?
How are expensive requests controlled?

These discussions distinguish a production design from a demo.

Question 1: Design ChatGPT

A ChatGPT-like system is one of the most comprehensive AI system design questions.

The functional requirements may include:

Starting a conversation
Sending prompts
Receiving streamed responses
Viewing conversation history
Regenerating an answer
Uploading files
Choosing among models
Enforcing free and paid usage limits

A useful high-level architecture contains the following components.

API gateway

The gateway handles authentication, request routing, rate limiting, quotas, and basic validation.

Long-running generation requests may use Server-Sent Events or WebSockets to stream tokens to clients.

Conversation service

This service manages:

Conversations
Messages
User preferences
Message ordering
Conversation titles
Retention and deletion

Conversation metadata can live in a transactional database, while large attachments may be placed in object storage.

Context builder

Models have finite context windows. The context builder decides what information should be included in the next request.

It may combine:

The system prompt
Recent conversation messages
A summary of older messages
Retrieved documents
User preferences
Tool outputs

Simply sending the entire conversation forever is expensive and eventually impossible. Older content may need summarization or selective retrieval.

Model gateway

The model gateway provides a single interface to multiple model backends.

It can route requests based on:

Task type
Required quality
User subscription
Context length
Latency target
Current capacity
Cost budget
Model availability

A simple request may use a smaller, faster model, while complex reasoning may be routed to a more capable one.

Inference scheduler

The scheduler assigns requests to model replicas running on accelerators.

It should consider:

Available GPU memory
Model placement
Prompt length
Output-token budget
Priority
Batch compatibility
Tenant quotas

A naive first-in, first-out scheduler can allow a few extremely long prompts to delay many short requests.

Streaming layer

Generated tokens should be forwarded incrementally to the user.

The system must also handle:

Client disconnections
User cancellation
Partial responses
Network retries
Moderation during generation
Final persistence after streaming completes

Safety layer

Input and output policies may detect:

Prompt injection
Sensitive information
Disallowed requests
Malicious files
Unsafe tool instructions
Data leakage

Safety should not be treated as one filter placed at the end. Different checks may be required before retrieval, before tool execution, before inference, and before returning the final response.

Important deep dives

An interviewer may ask:

How would you reduce time to first token?
How would you support 100 million users?
How would you prevent one tenant from consuming all GPU capacity?
How would you summarize long conversations?
How would you route between multiple models?
How would you preserve availability during GPU shortages?
How would you limit the cost for free users?

The Design ChatGPT walkthrough provides a structured example of this problem.

Question 2: Design a RAG System

Retrieval-augmented generation, or RAG, allows a model to answer using information retrieved from external sources.

A common interview prompt is:

Design an enterprise assistant that answers employee questions using internal documents and provides citations.

A RAG system has two major paths:

The ingestion path
The query path

The ingestion path

Documents may come from file uploads, internal wikis, cloud drives, databases, or support systems.

The ingestion pipeline performs several stages.

Document extraction

Files must be converted into usable text.

The system may need parsers for:

PDFs
Word documents
Presentations
HTML pages
Spreadsheets
Scanned images

The extraction process should preserve useful metadata such as titles, headings, page numbers, owners, and access permissions.

Chunking

Long documents are divided into smaller segments.

Chunks that are too large may contain irrelevant text and consume excessive context. Chunks that are too small may lose meaning.

Possible strategies include:

Fixed token windows
Paragraph-based chunking
Heading-aware chunking
Overlapping windows
Semantic chunking

There is no universally correct chunk size. It should be tested against representative questions.

Embedding generation

Each chunk is converted into a numerical vector using an embedding model.

The embedding service should be versioned because changing models can require re-embedding the entire corpus.

Indexing

The system stores:

Embeddings
Original text
Document metadata
Access-control information
Source location
Embedding version
Update timestamp

A vector index enables semantic retrieval. A traditional inverted index can support keyword retrieval. Many production systems combine both.

The query path

When a user submits a question:

Authenticate the user.
Generate an embedding for the query.
Retrieve candidate chunks.
Apply access-control filtering.
Rerank the candidates.
Select the best context.
Construct the prompt.
Generate the answer.
Attach citations.
Evaluate or log the result.

Hybrid retrieval

Semantic retrieval is useful when the query and source use different words with similar meanings.

Keyword retrieval is useful for exact terms such as:

Product codes
Error messages
Names
Dates
Identifiers

Combining both methods often produces better coverage.

Reranking

Vector similarity may retrieve documents that are generally related but not directly useful.

A reranker can score the top candidates more accurately before they are sent to the LLM. This improves answer quality while keeping the final prompt small.

Access control

Security is one of the most important parts of enterprise RAG.

A user should never retrieve a document they are not authorized to view. Filtering after the model has already received the document is too late.

Permissions should be enforced during retrieval, with tenant and user identity included in the query path.

Freshness and deletion

The system must react when:

A document changes.
A document is deleted.
Permissions change.
A user loses access.
A newer policy replaces an older one.

The ingestion pipeline may use event-driven updates, periodic crawling, or both.

RAG evaluation

A RAG system should separately evaluate:

Retrieval quality: Did the system find the relevant document?
Generation quality: Did the model use the retrieved context correctly?
Citation quality: Do the cited sources actually support the answer?

This separation is important. A poor answer can result from failed retrieval even when the model behaves correctly.

Question 3: Design an LLM Inference Platform

This question focuses less on the product interface and more on the infrastructure that serves models.

A possible prompt is:

Design a multi-tenant platform that serves several large language models to millions of requests.

The platform may need to support:

Multiple model families
Different model sizes
Streaming generation
Priority tiers
Autoscaling
Usage accounting
Model versioning
Regional deployment
Fine-tuned adapters

Inference gateway

The gateway exposes a consistent API and performs:

Authentication
Quota enforcement
Request validation
Model selection
Token-limit checks
Admission control
Cost estimation

Admission control is critical. Accepting unlimited work and allowing it to queue indefinitely creates poor latency and can destabilize the system.

Model registry

The registry tracks:

Model version
Artifact location
Supported hardware
Memory requirements
Context length
Quantization format
Deployment status
Safety and evaluation results

Rollouts should use immutable versions so requests and incidents can be traced to the exact model that served them.

Model placement

Loading a large model into GPU memory can take substantial time. The scheduler cannot treat models like lightweight stateless application containers.

It must decide:

Which models remain loaded
How many replicas each model receives
Where fine-tuned adapters are placed
When models should be unloaded
How capacity is distributed across regions

Popular models may remain warm, while rarely used models may accept a cold-start delay.

Prefill and decode

LLM inference contains two different computational phases.

Prefill processes the input prompt and can often benefit from parallel computation.

Decode generates tokens sequentially and is usually memory-bandwidth intensive.

Separating or independently scheduling these phases can improve utilization, but it also adds network and orchestration complexity.

Continuous batching

Instead of waiting for a fixed group of requests to finish together, continuous batching adds and removes requests dynamically as generation progresses.

This improves GPU utilization, especially when responses have different lengths.

The scheduler must still prevent long requests from starving shorter ones.

KV cache

The key-value cache stores intermediate attention state so the model does not recompute the entire prompt for every generated token.

KV-cache management affects:

Maximum concurrency
Memory pressure
Long-context support
Prefix reuse
Request eviction

A shared prompt prefix—such as a large system prompt—may sometimes be cached and reused across compatible requests.

Scaling

GPU utilization alone may not be sufficient for autoscaling.

Useful signals include:

Queue length
Time to first token
Tokens generated per second
KV-cache pressure
Number of active sequences
Predicted token demand
Model-specific backlog

Because accelerator provisioning may be slow, the platform may need reserved capacity and predictive scaling.

Graceful degradation

When capacity is limited, the system may:

Route to a smaller model.
Reduce the maximum output length.
Reject low-priority requests.
Disable expensive features.
Queue batch workloads.
Move traffic to another region.
Use a third-party model provider.

A strong interview answer discusses the quality and cost consequences of each fallback.

Question 4: Design an AI Agent Platform

An AI agent does more than produce text. It can plan a sequence of actions, call tools, observe results, update its state, and continue until a goal is completed.

A typical prompt might be:

Design an enterprise agent that can search internal documents, update tickets, send emails, and request human approval for sensitive actions.

Core components

Agent orchestrator

The orchestrator controls the execution loop:

Receive a goal.
Construct the current context.
Ask the model for the next action.
Validate the proposed action.
Execute the selected tool.
Store the result.
Decide whether to continue.
Produce the final response.

The orchestrator—not the model—should enforce hard limits such as maximum steps, timeouts, budgets, and approval requirements.

Tool registry

The tool registry describes each available capability:

Tool name
Purpose
Input schema
Required permissions
Timeout
Retry policy
Risk level
Whether human approval is required

Tool definitions should be versioned because changing their schemas can break existing agent behavior.

Tool execution service

Tool calls should run through controlled executors rather than allowing the model unrestricted access to internal systems.

The executor handles:

Authentication
Input validation
Secrets
Network policy
Timeouts
Retries
Audit logging
Output normalization

High-risk operations should use narrow, purpose-built APIs.

State and memory

Agents may need several kinds of memory.

Working memory contains the current task, observations, and intermediate steps.

Session memory preserves information during one user interaction.

Long-term memory stores information across sessions.

External memory may contain documents retrieved from databases or vector indexes.

Not everything should be stored forever. Memory needs explicit retention, privacy, and deletion policies.

Human approval

Actions such as sending payments, deleting data, publishing content, or modifying production systems should not be executed solely because a model requested them.

The agent can create a proposed action, pause its workflow, and wait for authorized approval.

The approval record should contain:

The intended action
The relevant parameters
Why it was proposed
The expected effect
The identity of the approver
An expiration time

Idempotency

Agents may retry actions after timeouts.

Without idempotency, a retry could send the same email twice, create duplicate tickets, or repeat a transaction.

Every state-changing tool call should include a stable execution identifier or idempotency key.

Agent-specific failure modes

A strong candidate should discuss:

Infinite planning loops
Repeated tool calls
Prompt injection inside retrieved content
Tool hallucination
Stale observations
Excessive cost
Partial workflow completion
Conflicting actions
Unauthorized data access

The system should impose:

Maximum step counts
Token budgets
Time limits
Per-tool permissions
Human checkpoints
Detailed audit logs
Recovery or compensation workflows

The Grokking Modern AI Fundamentals course can provide additional background on agentic AI, planning, memory, and tool-based behavior.

Additional AI System Design Questions to Practice

The four core questions cover much of the modern AI stack, but interviewers can frame the same concepts in narrower ways.

Design an enterprise AI copilot

Focus on tenant isolation, document permissions, RAG, conversation history, model routing, auditability, and data retention.

Design a coding assistant

Discuss repository indexing, code-aware chunking, low-latency suggestions, context selection, IDE integration, private-code protection, and evaluation of generated code.

Design an AI evaluation platform

Cover dataset versioning, offline evaluation, human review, model comparison, prompt experiments, regression detection, and production feedback.

Design a multi-model gateway

Explain routing between internal and third-party models based on cost, quality, latency, privacy, context length, and availability.

Design a semantic-search platform

Focus on ingestion, embeddings, vector indexes, hybrid retrieval, filtering, reranking, index updates, and relevance metrics.

Design an AI safety and guardrails service

Discuss policy versioning, input and output classification, prompt-injection detection, tool restrictions, personally identifiable information, appeals, and false-positive handling.

Design a prompt-management platform

Cover prompt templates, version control, experiments, rollout, rollback, tenant overrides, caching, and compatibility with changing model versions.

Design a multimodal assistant

Add image, audio, and document ingestion, media storage, preprocessing, modality-specific models, content safety, and larger payload management.

What Interviewers Look for in AI System Design Answers

A weak answer places an LLM box in the center of a diagram and connects it to an API.

A strong answer explains the system around the model.

Interviewers want to see whether you can reason about:

End-to-end architecture

Can you connect the client, application services, retrieval layer, model platform, storage, and observability systems?

Trade-offs

Can you compare:

Larger models versus smaller models
Quality versus latency
Quality versus cost
Long context versus retrieval
Hosted APIs versus self-hosting
Semantic retrieval versus keyword search
Autonomy versus human control

Reliability

Can the system continue operating when a model, vector index, tool, region, or third-party provider is unavailable?

Evaluation

Can you tell whether a new model or prompt actually improved the product?

Security

Can you protect tenant data, prevent unauthorized retrieval, constrain tool use, and manage sensitive prompts?

Cost

Can you estimate and control token usage, accelerator capacity, retrieval cost, storage, and third-party API spending?

The model is only one component. Production readiness comes from the architecture surrounding it.

How to Prepare

Candidates new to large-scale architecture should first learn the traditional foundations.

Grokking System Design Fundamentals introduces the core building blocks behind scalable systems, including databases, caches, queues, replication, partitioning, and load balancing.

The original Grokking the System Design Interview applies those concepts to common interview problems and teaches a structured way to move from requirements to architecture and trade-offs.

The System Design Interview Crash Course is useful for practicing a consistent interview framework across modern case studies, including a complete ChatGPT design problem.

Engineers preparing for senior and staff-level discussions can continue with Advanced System Design Interview, Volume II, which emphasizes open-ended problems, failures, and defensible architectural decisions.

Grokking Scalable Systems for Interviews is a useful next step for strengthening scalability, observability, fault tolerance, and performance reasoning.

For every AI design problem, practice three times:

Design the happy path.
Design for failure and overload.
Defend the quality, safety, and cost trade-offs.

That third pass is where most of the valuable interview discussion occurs.

Final Takeaway

AI system design is not a replacement for traditional system design.

It is a traditional system design combined with a new set of constraints.

You still need to understand APIs, storage, caching, queues, partitioning, replication, security, observability, and fault tolerance.

But you must now apply those concepts to systems with:

Probabilistic outputs
Expensive inference
Streaming generation
Vector retrieval
Dynamic prompts
Long-lived context
External tools
Model evaluation
Safety requirements
Human approval

Start with four foundational problems:

Design ChatGPT.
Design a RAG platform.
Design an LLM inference service.
Design an AI agent platform.

Master the request flow, deep dives, failure modes, and trade-offs behind each one.

Once you can explain those systems clearly, most other AI system design questions become variations of the same underlying building blocks.

System Design Interview Questions by Level: Junior, Mid-Level, Senior, and Staff

Arslan Ahmad — Thu, 25 Jun 2026 11:25:18 +0000

System Design Interview Questions by Level: Junior, Mid-Level, Senior, and Staff

Not every system design interview evaluates the same thing.

A junior engineer may be asked to design a URL shortener and explain why a cache would help. A mid-level engineer could receive the same question but be expected to estimate traffic, choose a database, and handle key collisions.

A senior engineer may need to discuss multi-region deployment, consistency, failure recovery, and operational trade-offs. A staff engineer could be pushed further into migration strategy, organizational boundaries, cost, and the long-term evolution of the platform.

The question may look identical. The expected answer is not.

This is why preparing from one enormous, unstructured list of system design questions can be misleading. Candidates often spend time on problems that are far above or below the depth required for their target role.

A better approach is to organize your preparation around the level you are targeting.

This guide breaks system design interview questions into four groups:

Junior engineers
Mid-level engineers
Senior engineers
Staff engineers

For a broader collection covering every difficulty tier, see the complete pillar guide: 64 System Design Interview Questions, Ranked From Easiest to Hardest.

The goal here is different. Instead of simply listing questions, we will examine what interviewers expect from candidates at each engineering level.

What Changes as You Move Up the Engineering Ladder?

System design interviews become harder with seniority, but not simply because the systems become larger.

The most important change is the depth of reasoning expected from you.

A junior candidate is usually evaluated on whether they understand fundamental building blocks.

A mid-level candidate must connect those building blocks into a scalable architecture.

A senior candidate must anticipate failures, challenge assumptions, and defend architectural trade-offs.

A staff candidate must think beyond the immediate system and consider its interaction with teams, platforms, migrations, business constraints, and long-term technical strategy.

A simplified progression looks like this:

Level	Primary expectation
Junior	Understand the basic components and produce a workable design
Mid-level	Build a scalable end-to-end system and explain major trade-offs
Senior	Handle ambiguity, failures, correctness, and operational complexity
Staff	Shape the problem, evaluate long-term consequences, and lead the design discussion

Your preparation should reflect this progression.

Junior-Level System Design Interview Questions

Junior engineers are not normally expected to design a globally distributed platform from first principles.

Interviewers are more interested in whether you can:

Clarify basic requirements.
Identify the main entities.
Define simple APIs.
Choose reasonable storage.
Understand caching and load balancing.
Estimate basic traffic and storage.
Explain how the system could scale beyond one server.

The best junior-level questions usually focus on one dominant concept.

1. Design TinyURL

A URL shortener is one of the best starting points for system design preparation.

The core workflow is simple:

A user submits a long URL.
The system generates a short identifier.
The identifier is stored with the original URL.
Requests to the short URL are redirected.

A junior candidate should be able to discuss:

The API for creating and resolving links.
Generating unique short keys.
Handling collisions.
Storing URL mappings.
Caching frequently accessed links.
Expiring links when necessary.

Do not overcomplicate the first version. Start with a single service and database, then explain how load balancers, replicas, and caches could be introduced as traffic increases.

2. Design Pastebin

Pastebin extends the URL-shortening problem by adding larger content, expiration, and access control.

Important questions include:

Should paste content and metadata live together?
How will pastes expire?
How will private pastes be protected?
Where should large text objects be stored?
How can popular pastes be served quickly?

This problem teaches an important system design lesson: different types of data may require different storage strategies.

3. Design an API Rate Limiter

A rate limiter controls how many requests a user or client can send during a given period.

Junior candidates should understand the basic algorithms:

Fixed window
Sliding window
Token bucket
Leaky bucket

The interview is not only about naming an algorithm. You should explain where counters are stored, how limits are associated with users, and what response is returned when the limit is exceeded.

A simple in-memory solution is acceptable initially. You can then introduce a shared store such as Redis when multiple application servers need access to the same counters.

4. Design a Unique ID Generator

Distributed systems frequently need identifiers for users, orders, posts, messages, and transactions.

The problem appears easy until several machines must generate IDs simultaneously.

A junior-level discussion may compare:

Auto-incrementing database IDs
Random UUIDs
Timestamp-based identifiers
Preallocated ID ranges
Snowflake-style IDs

Focus on uniqueness first. Ordering, clock drift, and coordination can be introduced as deeper follow-up topics.

5. Design Typeahead Suggestions

A typeahead service returns suggestions while a user is entering a search query.

The design introduces:

Prefix lookup
Tries and prefix indexes
Popularity ranking
Caching
Latency requirements
Updating trending queries

The most important lesson is that the system cannot scan every possible query after each keystroke. It needs a data structure or precomputed index that supports fast prefix retrieval.

6. Design an API Gateway

An API gateway sits between clients and backend services.

A foundational design should explain how it handles:

Request routing
Authentication
Rate limiting
Logging
Response aggregation
Protocol transformation

This question helps junior engineers understand how clients interact with a microservice architecture without calling dozens of internal services directly.

What a Strong Junior Answer Looks Like

A good junior-level answer does not need to include every distributed-systems technique.

It should demonstrate a clear thought process:

Clarify what the system must do.
Define the main API operations.
Choose a simple data model.
Draw the initial architecture.
Identify the likely bottleneck.
Explain one or two ways the design could scale.

Candidates preparing for their first system design interview can begin with Grokking System Design Fundamentals and then progress to the original Grokking the System Design Interview.

Mid-Level System Design Interview Questions

Mid-level engineers are expected to move beyond isolated components.

Your design should include a complete flow from the client request to storage, processing, and delivery. You should recognize common bottlenecks without waiting for the interviewer to point them out.

Interviewers may expect you to discuss:

Read-heavy versus write-heavy workloads.
Database partitioning.
Replication.
Cache placement and invalidation.
Asynchronous processing.
Message queues.
Eventual consistency.
Basic failure recovery.
Trade-offs between different designs.

The questions at this level often involve familiar consumer products.

1. Design Twitter

The central challenge in Twitter is generating a user’s home timeline.

Two common strategies are:

Fan-out on write: When a user posts, the system pushes the post into followers’ timelines.

Fan-out on read: When a user opens the application, the system retrieves recent posts from everyone they follow.

Fan-out on write improves read latency but creates enormous write amplification for accounts with millions of followers. Fan-out on read avoids those writes but makes timeline retrieval more expensive.

A strong mid-level candidate should recognize that a hybrid strategy may work best.

2. Design Instagram

Instagram introduces media upload, processing, storage, and delivery.

Your design should separate:

Media metadata
Original image or video files
Derived formats and thumbnails
Feed-generation data

Application servers should not repeatedly serve large media files. Object storage and a content delivery network are better suited for that workload.

Other useful discussion areas include privacy, upload retries, feed generation, and handling popular posts.

3. Design Facebook Messenger or WhatsApp

A messaging service requires more than storing messages.

You should consider:

Persistent connections
Message routing
Delivery acknowledgments
Offline delivery
Conversation history
Message ordering
Retries and deduplication
Multi-device synchronization

The phrase “exactly-once delivery” should be used carefully. In practice, messaging systems often combine at-least-once delivery with idempotency and deduplication.

4. Design Dropbox

Dropbox tests both server-side and client-side reasoning.

Important concepts include:

Breaking files into chunks.
Uploading only changed chunks.
Deduplicating identical data.
Synchronizing files across devices.
Handling concurrent updates.
Maintaining version history.
Storing metadata separately from file content.

The client plays a significant role because it monitors local changes and communicates them efficiently to the server.

5. Design Uber

Uber combines geospatial search with frequently changing state.

The system needs to:

Receive driver-location updates.
Find available drivers near a rider.
Match drivers with trips.
Track trip state.
Calculate estimated arrival times.
Handle sudden regional demand spikes.

A mid-level candidate should be comfortable discussing geohashes or another spatial partitioning technique, but the conversation should not end there. You must also explain how the location index stays current and how matching requests avoid conflicts.

6. Design Yelp or Nearby Friends

This question focuses on finding entities within a geographic area.

Potential approaches include:

Geohashing
Quadtrees
Grid-based indexes
Spatial database indexes

The design should account for uneven density. A geographic cell in a rural area may contain almost nothing, while a similarly sized cell in Manhattan may contain thousands of businesses or users.

7. Design Ticketmaster

Ticketmaster introduces temporary reservations and strong correctness requirements.

The system must prevent two customers from purchasing the same seat.

Important topics include:

Seat-locking mechanisms
Reservation expiration
Waiting rooms
Handling flash traffic
Payment failures
Idempotent booking operations
Releasing abandoned reservations

This question helps distinguish systems where eventual consistency is acceptable from systems where it could create serious business problems.

8. Design a Notification System

A notification platform may deliver:

Push notifications
Emails
SMS messages
In-app notifications

A good architecture separates notification creation from delivery by placing events on queues. Independent workers can then process different channels.

The system should also respect user preferences, retry temporary failures, prevent duplicates, and enforce provider-specific rate limits.

What a Strong Mid-Level Answer Looks Like

A strong mid-level candidate should be able to:

Complete the end-to-end design.
Estimate the dominant workload.
Explain the main read and write paths.
Select storage based on access patterns.
Use queues for work that does not need to happen synchronously.
Identify hotspots and single points of failure.
Compare at least two possible approaches to the central problem.

The original Grokking the System Design Interview is especially relevant at this stage because it combines system design fundamentals, recurring trade-offs, and classic interview problems.

Senior-Level System Design Interview Questions

Senior candidates are expected to take ownership of the discussion.

The interviewer may deliberately leave the prompt vague. Rather than asking for every requirement individually, you should identify the assumptions that materially affect the architecture.

Senior interviews tend to emphasize:

Failure modes.
Multi-region operation.
Data consistency.
Idempotency.
Observability.
Backpressure.
Capacity planning.
Operational complexity.
Security and privacy.
Cost-aware architecture.
Migration and rollout strategies.

Simply drawing more boxes does not make an answer senior-level. Depth comes from anticipating what could go wrong.

1. Design Google Docs

Real-time collaborative editing requires multiple users to update the same document concurrently.

The key problem is convergence: all clients must eventually agree on the same document state, even when operations arrive in different orders.

A strong discussion may include:

Operational transformation
Conflict-free replicated data types
Operation logs
Document snapshots
Cursor and presence updates
Reconnection after network failure
Version history
Permission changes during a session

Senior candidates should explain which updates require durability and which can be treated as temporary presence information.

2. Design ChatGPT

Designing ChatGPT combines conventional application infrastructure with large-model inference.

The product layer may require:

Authentication
Conversation history
Usage limits
Billing
Streaming responses
Safety enforcement

The model-serving layer introduces:

GPU scheduling
Request batching
Model routing
Token streaming
Context management
KV-cache management
Capacity and cost control

The interviewer may not expect a detailed explanation of model training. A strong candidate clearly defines the scope and focuses on the online serving system.

3. Design a Distributed Cache

A distributed cache such as Redis introduces several difficult concerns:

Partitioning
Replication
Eviction
Expiration
Cache invalidation
Hot keys
Cache stampedes
Node failure
Rebalancing

A senior candidate should discuss what happens during partial failure, not merely describe the happy path.

For example, when an expired popular key receives thousands of simultaneous requests, those requests may all hit the database. Request coalescing, staggered expiration, and stale-while-revalidate are possible protections.

4. Design a Payment System

Payments are dominated by correctness rather than raw scale.

Important concepts include:

Idempotency keys
Immutable transaction records
Double-entry ledgers
Payment state machines
Reconciliation
Webhook retries
Duplicate events
Refunds and chargebacks
Unknown transaction outcomes

A network timeout does not prove that a payment failed. The request may have succeeded while the response was lost. The architecture must preserve this uncertainty and resolve it safely.

5. Design Amazon S3

An object-storage system must provide extraordinary durability while serving huge volumes of reads and writes.

A senior-level design should address:

Object and bucket metadata
Data partitioning
Replication or erasure coding
Checksums
Multipart uploads
Versioning
Lifecycle management
Corruption detection
Background repair
Hot partitions
Regional failures

The metadata plane and object data plane should be considered separately.

6. Design a Metrics and Monitoring System

Monitoring systems ingest large volumes of time-series data.

Important concerns include:

High-throughput ingestion
Metric labels and cardinality
Time-based partitioning
Downsampling
Retention
Aggregation
Query performance
Alert evaluation
Late-arriving data
Regional collection

One of the most important discussions is cardinality. A seemingly harmless label such as a unique user ID can produce an unsustainable number of time series.

7. Design a Code Deployment System

A deployment platform coordinates changes across large fleets of machines or containers.

A strong design should include:

Build artifacts
Deployment manifests
Canary releases
Blue-green deployments
Health checks
Progressive rollout
Automated rollback
Audit logs
Configuration management
Regional sequencing

The senior-level challenge is not merely deploying the new version. It is limiting the blast radius when that version is defective.

What a Strong Senior Answer Looks Like

Senior candidates should lead rather than follow.

That means:

Narrowing an ambiguous problem.
Prioritizing the most important quality attributes.
Making assumptions explicit.
Identifying failure scenarios before being prompted.
Explaining operational consequences.
Choosing the deep dive that best demonstrates judgment.
Acknowledging where the design creates future complexity.

Engineers targeting senior and L5/L6 roles can use Grokking the System Design Interview, Volume II for more advanced distributed-systems problems and deeper trade-off analysis.

Staff-Level System Design Interview Questions

Staff-level interviews are not simply senior interviews with larger numbers.

The candidate is expected to reason across systems, teams, and time horizons.

A staff engineer should be able to discuss:

Platform boundaries.
Ownership between teams.
Incremental migrations.
Build-versus-buy decisions.
Long-term data models.
Cross-region architecture.
Compliance and security.
Cost and organizational constraints.
Standardization versus team autonomy.
How the system evolves over several years.

The interviewer may care more about how you frame the problem than about the final diagram.

1. Design a Stock Exchange

A stock exchange requires deterministic ordering, low latency, and strict correctness.

The design should cover:

Order submission
Sequencing
Order books
Matching engines
Market-data distribution
Persistence and replay
Risk controls
Failure recovery
Auditability

Partitioning by financial instrument can improve scalability, but each order book needs a clear source of authority.

2. Design a Distributed Lock Manager

Distributed locking introduces:

Consensus
Leases
Session expiration
Leader election
Fencing tokens
Split-brain prevention
Clock and network uncertainty

A staff candidate should understand why acquiring a lock is not enough. A paused or partitioned client might continue operating after its lease has expired. Fencing tokens can help downstream resources reject stale owners.

3. Design a Distributed Job Scheduler

A global scheduler must trigger jobs at the correct time, distribute work, and recover from failures.

Challenges include:

Sharding schedules.
Leader election.
Worker coordination.
Duplicate execution.
Missed schedules.
Long-running jobs.
Retries.
Backpressure.
Time-zone handling.
Disaster recovery.

The candidate should distinguish between guaranteeing that a job is dispatched and guaranteeing that its business effect occurs only once.

4. Design Apache Kafka

Kafka is best understood as a distributed append-only log rather than a conventional queue.

A staff-level discussion may cover:

Partitioning
Consumer groups
Offset management
Replication
Leader election
Retention
Log compaction
Rebalancing
Delivery semantics
Cross-region replication

The design should also consider how Kafka would be operated as a shared organizational platform without allowing one workload to destabilize everyone else.

5. Explain Amazon Dynamo

Dynamo provides a rich case study in availability-oriented storage.

Core topics include:

Consistent hashing
Replication
Quorum reads and writes
Vector clocks
Sloppy quorums
Hinted handoff
Read repair
Merkle trees

At staff level, do not just define these mechanisms. Explain why Dynamo chose them and which workloads are compatible with those trade-offs.

6. Explain Cassandra

Cassandra combines Dynamo-inspired distribution with an LSM-tree-based storage engine.

A strong discussion may include:

Partition keys
Tunable consistency
Commit logs
Memtables
SSTables
Bloom filters
Compaction
Tombstones
Repair
Hot partitions

The schema must be designed around queries. Poor partition-key selection can undermine an otherwise scalable architecture.

7. Explain Google File System and Bigtable

These systems show how infrastructure components can be composed.

Google File System is optimized around large files, sequential access, append-heavy workloads, and frequent machine failure.

Bigtable builds a distributed, sorted storage abstraction while relying on other infrastructure for persistent storage and coordination.

The broader staff-level lesson is that architecture is shaped by workload assumptions. A design that is excellent for one environment may be inappropriate for another.

What a Strong Staff Answer Looks Like

A staff-level candidate should be able to:

Reframe the prompt around business and technical priorities.
Establish architectural principles.
Identify the interfaces between major subsystems.
Explain how multiple teams could own and evolve the system.
Propose an incremental path rather than a risky rewrite.
Compare technical complexity with operational and organizational costs.
Recognize when the system should use an existing platform instead of building a new one.
Discuss how the architecture behaves during rare but severe failures.

Staff interviews are less about producing the largest possible diagram and more about demonstrating durable technical judgment.

The Same Question Can Be Asked at Every Level

Consider the instruction:

Design a URL-shortening service.

A junior candidate may focus on the API, short-code generation, database schema, and cache.

A mid-level candidate may add traffic estimates, partitioning, replication, expiration, analytics, and abuse prevention.

A senior candidate may discuss global routing, multi-region consistency, disaster recovery, hot-key protection, observability, and safe migrations.

A staff candidate may ask whether the organization should build a shared link-management platform, how several product teams would integrate with it, how privacy policies would be enforced, and how the service could migrate from an existing system without breaking billions of links.

The prompt stayed the same.

The evaluation level changed.

This is why memorizing one “correct” architecture is not enough. Your answer must reflect the depth expected from the role.

How Many Questions Should You Practice?

You do not need to complete every system design question ever published.

A more effective preparation plan is:

Junior candidates

Practice five to eight foundational problems deeply.

Mid-level candidates

Practice approximately ten to fifteen problems covering social feeds, messaging, file storage, geospatial search, booking, and notifications.

Senior candidates

Practice fifteen to twenty problems, with additional attention to payments, infrastructure, observability, collaboration, storage, and failure handling.

Staff candidates

Practice fewer problems at greater depth. Add production case studies and distributed-systems papers to your preparation.

The complete 64-question system design roadmap can help you select problems that match your target level.

For every problem, use three passes:

Learn: Study the architecture and central trade-offs.
Reconstruct: Design the system again without looking at the solution.
Defend: Explain failures, alternatives, costs, and why your decisions fit the requirements.

The third pass is where interview readiness develops. The fastest way to test it is a timed mock interview, where someone else pushes on your weakest decision. This system design mock interview guide shows how many mocks to do at each stage and which platforms to use.

Choosing the Right System Design Preparation Path

Your preparation resources should match your current level.

Newer engineers may begin with Grokking System Design Fundamentals to build familiarity with scalability, databases, caching, replication, partitioning, messaging, and other architectural building blocks.

Junior and mid-level candidates can continue with the original Grokking the System Design Interview, which applies those concepts to classic interview questions.

Senior and staff candidates should add Grokking the System Design Interview, Volume II, where the emphasis moves toward more complex distributed systems, deeper failure analysis, and defensible architectural decisions.

Candidates working with a limited preparation window can also use the System Design Interview Crash Course as a structured review of system design frameworks and modern design problems.

The broader DesignGurus System Design Interview Guide can serve as a central reference for frameworks, concepts, questions, and study resources.

Final Takeaway

The best system design preparation is not based on solving the greatest possible number of questions.

It is based on practicing the right questions at the right depth.

Junior engineers should build confidence with focused, single-concept systems.

Mid-level engineers should learn to connect components into scalable end-to-end architectures.

Senior engineers should anticipate failures, defend trade-offs, and account for operational complexity.

Staff engineers should shape the problem, guide long-term architecture, and reason across systems, teams, and organizational constraints.

As you move up the engineering ladder, the interviewer becomes less interested in whether you know a particular component and more interested in whether you can make sound decisions under uncertainty.

That is the real progression from junior to staff-level system design.

Must do system design interview questions required for each software engineering level.

Arslan Ahmad — Sat, 09 May 2026 16:07:42 +0000

Arslan Ahmad

Apr 12

64 System Design Interview Questions, Ranked From Easiest to Hardest

#systemdesign #softwaredevelopment #interview #ai

19 min read

DEV Community: Arslan Ahmad

The 2027 System Design Interview Playbook: Framework, Concepts, and a Full Worked Example

TL;DR: The 60-Second Version

Table of Contents

What Is a System Design Interview?

What's Different About System Design Interviews in 2027

The Types of System Design Interviews

How You're Evaluated (and What Changes by Level)

The 7-Step System Design Interview Framework

Step 1: Clarify Requirements (≈5 minutes)

Step 2: Back-of-the-Envelope Estimation (≈3–5 minutes)

Step 3: Define the API (≈3–5 minutes)

Step 4: Model the Data (≈3–5 minutes)

Step 5: High-Level Design (≈8–10 minutes)

Step 6: Deep Dives (≈10–12 minutes)

Step 7: Bottlenecks, Failures, and Wrap-up (≈5 minutes)

Core Concepts: The System Design Toolkit

1. Scalability: Vertical vs Horizontal

2. Load Balancing

3. Caching

4. Content Delivery Networks (CDNs)

5. Databases: SQL vs NoSQL

6. Indexing

7. Replication

8. Sharding (Partitioning) and Consistent Hashing

9. CAP and PACELC

10. Consistency Models

11. Message Queues and Event-Driven Architecture

12. Rate Limiting

13. Idempotency and Retries

14. Unique ID Generation

15. Observability and Reliability

The Trade-offs Interviewers Love to Probe

Full Worked Example: Design a News Feed

Step 1: Requirements

Step 2: Estimation

Step 3: API

Step 4: Data Model

Step 5: High-Level Design

Step 6: Deep Dives

Deep Dive 1: Fan-out on Write vs Fan-out on Read

Deep Dive 2: The Feed Read Path and the 200 ms Budget

Deep Dive 3: Hot Keys and Celebrities

Deep Dive 4: Consistency and Ordering

Deep Dive 5: Ranking (if the Interviewer Asks)

Step 7: Bottlenecks, Failures, and Monitoring

How the Same Answer Looks at L4, L5, and L6

Bonus: A Template for AI System Design Questions

The Most Common System Design Interview Questions

12 Mistakes That Sink Strong Candidates

An 8-Week Preparation Plan

Best Resources to Prepare

FAQ

How long should I prepare for a system design interview?

Do I need distributed systems experience to pass?

Are system design interviews asked for junior and new-grad roles?

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

Should I memorize designs for popular questions?

How do I practice system design on my own?

How are AI tools changing the system design interview?

What's the single most important thing to get right?

Final Thoughts

Grokking the System Design Interview: How to Design a Rate Limiter (Step by Step)

What Is a Rate Limiter?

Step 1: Clarify the Requirements

Step 2: Back-of-the-Envelope Estimates

Step 3: Pick a Rate Limiting Algorithm

1. Token Bucket

2. Leaky Bucket

3. Fixed Window Counter

4. Sliding Window Log

5. Sliding Window Counter

Quick Comparison

Step 4: High-Level Design

Where should the rate limiter live?

Why Redis?

Response headers

Step 5: Deep Dives (Where Senior Candidates Shine)

Deep Dive 1: Race Conditions

Deep Dive 2: Scaling Redis