DEV Community: Arslan Ahmad

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.

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 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.

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.

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.

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

The 9 Things Engineers Get Wrong About the System Design Interview (and the 185 Articles I Wrote to Fix Them)

Arslan Ahmad — Mon, 13 Apr 2026 08:38:14 +0000

Every time I sit down to run a system design mock interview, the candidate fails for one of nine reasons.

Not ten. Not seven. Nine.

I've been doing this long enough — coaching engineers, running mocks, swapping debrief notes with hiring managers at Google, Meta, Amazon, Netflix, Microsoft, OpenAI, and a long tail of smaller companies — that the patterns have stopped surprising me. The same nine misconceptions show up in candidate after candidate, regardless of seniority. A junior at a startup makes the same mistakes as a staff engineer at a unicorn. Not the same magnitude, but the same shape.

Over the years, I've written 185+ articles on DesignGurus.io and DEV Community trying to address these exact failure modes one at a time. This essay pulls all of them together, organized not by topic — that's the way I usually shelf them — but by the misconception each one actually exists to correct.

If you're prepping for a system design interview right now, this is the order I'd hand the articles to you in. Read each section. Ask yourself honestly whether the misconception applies to you. Only then click into the posts. The goal isn't to read all 185. The goal is to read the ones that fix what's actually broken in your prep.

One quick note on audience. I write for engineers from junior all the way up through staff, plus engineering managers. Almost every misconception below applies across the board, but where a particular section skews toward one group, I'll say so. Engineering managers especially: don't skip Section 9. The gap between EMs who pass design loops and EMs who don't is almost never about technical depth.

Alright. Here are the nine.

Misconception #1: "It's a memorization test."

This is the most common one, and the most expensive.

Engineers walk in thinking the system design interview is a quiz: name three load balancing algorithms, define CAP theorem, list the four Vs of big data. They study it the way you'd study for a vocabulary test. Then they walk into the room, the interviewer says "design Twitter," and they freeze — because flash cards don't tell you how to start.

The system design interview is not a quiz. It's a structured conversation that tests whether you can reason about ambiguity, gather requirements, make trade-offs out loud, and defend your decisions when challenged. The vocabulary matters — you can't have the conversation without the words — but the vocabulary is the floor, not the ceiling. What you actually need first is a method. A repeatable approach you can fall back on when your brain goes blank.

These are the articles that give you one.

Grokking System Design: A Complete Roadmap for 2026 — If I could hand you a single starting point, this would be it.
2025 System Design Roadmap: From Beginner to Advanced — A second pass at the roadmap if you want a different angle on the same path.
How to Prepare for System Design Interview in 2026 — Concrete weekly cadence for engineers who don't know what "study" even looks like for this round.
How to Approach Any System Design Question — A universal opening framework that works on whatever prompt the interviewer lobs at you.
Your 7-Day System Design Interview Prep Plan — For when your loop is one week away and panic is setting in.
Last-Minute System Design Prep — For when your loop is tomorrow morning.
How to Gather and Prioritize Requirements — The first five minutes of the interview, broken down so you don't waste them.
System Design Interview Prep Guide: 7 Steps — A clean seven-step framework for going from zero to ready.
System Design Interview Guide — 7 Steps to Ace It — The same seven steps, but mapped to what you do live in the room.
System Design Interviews: A Step-By-Step Guide — My Dev Community version of the same step-by-step framework.
Mastering the System Design Interview: A Complete Guide — A long-form guide for engineers who want one canonical reference.
Mastering the System Design Interview: Landing Your Dream Job — The companion piece focused on converting prep into outcomes.
System Design Mastery: Your Roadmap to Acing Interviews — A more advanced roadmap aimed at senior+ candidates.
Demystifying System Design Interviews — What's actually happening on the interviewer's side of the table.
A Comprehensive Breakdown of Systems Design Interviews — The hidden rubric you're being graded on, made explicit.
How To Clear System Design Interview: A Quick Guide — A ruthlessly compressed checklist for passing the round.
7 Tips to Stand Out in Your System Design Interview — How "pass" candidates become "strong hire" candidates.
How 4 Candidates Passed FAANG System Design Interviews — Four real stories that will calm you down if you're spiraling.

Misconception #2: "I know what consistency means."

You probably don't.

Or — more precisely — you know the textbook definition but you can't actually distinguish strong from eventual consistency in a real design conversation, you can't explain when each is appropriate, and you'll mumble something about CAP theorem if you get pushed on it. I've seen this in candidates with eight years of experience.

The fundamentals are called fundamentals because everything else stacks on top of them. If you can't speak fluently about consistency, caching, load balancing, hashing, rate limiting, idempotency, and back-of-the-envelope estimation, the rest of your prep is a house built on sand. This is the section to go deepest on, even if you think you already know this stuff. Especially if you think you already know this stuff.

25 Fundamental System Design Concepts — The twenty-five-concept checklist I run through to gauge readiness.
4 Basic Pillars of System Design — Scalability, availability, reliability, performance — the four qualities you're scored on.
12 System Design Algorithms You Must Know — The dozen algorithms quietly powering most distributed systems.
Eventual vs Strong Consistency — How to talk about consistency without sliding into academic jargon.
Consistency Patterns in Distributed Systems — A tour of the major consistency models and the situations each is built for.
CAP vs PACELC — Why senior interviewers have quietly upgraded from CAP to PACELC.
Load Balancing Algorithms Guide — The algorithms living inside every load balancer, explained without theory bloat.
Complete Load Balancer Guide 2026 — The 2026 deep dive on load balancers in real production deployments.
Mastering the Art of Caching — Cache layers, eviction strategies, and the pitfalls nobody warns juniors about.
Cache Invalidation Strategies — The hardest problem in computer science, finally given a serious treatment.
CDN System Design Basics — When a CDN earns its place in your diagram and when it's just resume garnish.
Consistent Hashing vs Traditional Hashing — The hashing technique that quietly makes horizontal sharding even possible.
Grokking Rate Limiters — Token buckets, leaky buckets, and how to actually implement one on a whiteboard.
Grokking Webhooks — Why webhooks beat polling and how to design them so they don't blow up.
Grokking Events in System Design — What the word "event" really means once you're inside an event-driven architecture.
Grokking Idempotency — The single key concept that keeps distributed systems from corrupting themselves.
Concurrency vs Parallelism — A distinction that more than half my mock candidates get wrong on the first try.
Synchronous vs Asynchronous Communication — The hidden operational cost of going async, and when you should pay it anyway.
Stateless vs Stateful — The single biggest lever you have for horizontal scale.
Mastering Estimation in System Design Interviews — How to do capacity math live without freezing or hand-waving.
Back-of-the-Envelope Estimation — The "numbers every programmer should know," updated for modern interviews.
Observer vs Pub-Sub Pattern — Two patterns that look identical from a distance and behave nothing alike up close.

Misconception #3: "Database choice doesn't really matter."

It's the entire interview.

Walk through any "design X" question that ever gets asked, and you'll find the data layer is where the candidate either earns the offer or loses it. Sharding strategies, replication topology, indexing decisions, the SQL-versus-NoSQL fork — these aren't side topics. They are the conversation.

I've watched too many candidates draw a beautiful service diagram and then wave vaguely at a cylinder labeled "DB" as if the storage layer were beneath their notice. It isn't. Senior interviewers spend half the round on data, and they grade you on how comfortable you are with the trade-offs.

PostgreSQL vs MongoDB vs DynamoDB — The three databases you'll be asked about most, compared honestly.
NoSQL Databases in System Design Interviews — A principled framework for when reaching for NoSQL is actually the right call.
Graph Databases 101 — The class of problem graph databases solve elegantly that relational ones can't.
Why Horizontally Scaling SQL Is Hard — The structural reasons relational systems fight you when you try to scale them out.
Scaling SQL Databases: 8 Challenges — The specific problems you'll hit when you push SQL past its comfort zone anyway.
Complete Database Sharding Guide 2026 — Every sharding strategy worth knowing, plus how each one fails.
Database Replication Fundamentals — Master-slave, multi-master, and quorum replication, demystified.
Data Replication Strategies I Wish I'd Known Earlier — The replication patterns I had to learn the hard way.
B-Tree vs Hash vs R-Tree — Three index structures and the workloads each is built for.
Database Indexing Demystified — A second take on indexing that brings bitmap indexes into the picture.
Grokking Database Indexing — Why indexes make queries fast, derived from first principles.
Normalization vs Denormalization — The eternal "it depends" question, finally given some actual rules.
ACID & Database Transactions 101 — Four letters every candidate should be able to riff on without notice.
From UUID to Snowflake — Why distributed ID generation is its own surprisingly deep topic.
Change Data Capture 101 — How CDC pipelines keep downstream systems coherent without dual writes.
Ultimate Guide to Redis in System Design — Redis explained through the lens of how it actually shows up in interviews.

Misconception #4: "Fast and scalable mean the same thing."

They don't.

A fast system can be impossible to scale. A scalable system can have terrible per-request latency. They are orthogonal qualities, optimized with different techniques, and conflating them is one of the cleanest tells that a candidate hasn't built distributed systems in production. When an interviewer asks "how would you make this faster?" and you start talking about adding more servers, you've revealed the gap.

This section covers the trade-off conversations that show up in every senior loop: scale versus latency, availability versus consistency, build versus buy, performance versus cost. Master these and you'll start sounding like an engineer who's actually shipped something at scale.

Grokking Scalability in System Design — The core mental models for thinking about scale from day one.
Scaling 101 — A thorough primer on scaling real-world systems beginning to end.
Large-Scale System Design Questions — Walkthroughs of questions that operate at billion-user scale.
High Availability — 15 Strategies — Fifteen concrete patterns for keeping a system up through failure.
Autoscaling Strategies — The autoscaling approaches that hold up when traffic actually spikes.
5 Best Leader Election Algorithms — The leader-election algorithms senior interviewers expect you to know on sight.
Best 5 Ways To Reduce Latency — Five concrete levers when "make it faster" lands on your desk.
Demystifying Long-Tail Latency — Why p99 is the number that matters and how to actually attack it.
Read-Heavy vs Write-Heavy Workloads — How to shape your architecture around your read-write ratio.
Top 10 System Design Challenges — The hardest problems in modern distributed systems engineering.
Top 12 System Design Trade-offs — The trade-offs that surface in nearly every senior loop.
System Design Trade-offs Framework — A framework for talking through trade-offs the way a senior engineer would.
Navigating Complex System Design Trade-Offs — Advanced trade-off analysis for staff-level conversations.
The Buy vs Build Decision — How to frame the off-the-shelf-versus-build-it-yourself question convincingly.

Misconception #5: "An API is just an API."

Tell me you haven't done a system design interview without telling me you haven't done a system design interview.

Modern interviews — especially at companies that ship a lot of services — care a lot about how those services talk to each other. Choosing REST versus GraphQL versus gRPC isn't a stylistic preference; it's a load-bearing architectural decision. The differences between a load balancer, a reverse proxy, and an API gateway aren't trivia; they're three different places to put cross-cutting concerns, and interviewers will probe whether you know the difference.

If your last meaningful API design conversation was about whether to use PUT or PATCH, this section is for you.

HTTP/2 vs HTTP/1.1 — The protocol upgrades that genuinely move the needle on performance.
TCP vs UDP — When UDP is the right call and when TCP is non-negotiable.
Cookies vs Sessions 101 — Web session management for engineers who never properly learned the basics.
What Happens When You Type a URL? — The classic warm-up question, walked through end to end.
What is an API? — A first-principles definition for engineers who've used APIs without ever defining one.
Understanding RESTful APIs — What "RESTful" means in interviews versus how it gets butchered in production.
10 Best API Design Practices — Ten habits that mark the difference between a junior and senior API designer.
The API Design Checklist — The mental checklist senior engineers run through before writing any endpoint.
REST vs GraphQL vs gRPC — A head-to-head on the three API paradigms competing for your design.
8 REST API Interview Questions — The REST-flavored questions that keep cycling back through interviews.
Mastering the API Interview — A deep dive on the API-focused round if your target company runs one.
Load Balancer vs Reverse Proxy vs API Gateway — Three boxes that look identical and serve very different purposes.
RabbitMQ vs Kafka vs ActiveMQ — The three message brokers you'll be asked about, head-to-head.
Kafka Streams vs Flink vs Storm — The major stream processing engines, compared by what they're actually good at.
Defensive Coding for Network Timeouts — The defensive patterns that prevent local failures from cascading into outages.
Grokking Messaging Patterns — Queues, Pub/Sub, and event streams — the three workhorses of distributed comms.

Misconception #6: "Microservices are obviously the right answer."

They're obviously the right answer the way a chainsaw is obviously the right tool for opening a letter.

I've lost count of the number of candidates who reach for microservices reflexively when asked to design even modestly sized systems. They name-drop service meshes, mention Kubernetes for no clear reason, and end up with diagrams that have more boxes than the actual product would have users in its first year.

A senior engineer knows when not to use microservices. A senior engineer can defend a monolith. A senior engineer can articulate what SOA actually was, what each style's failure modes look like in production, and when "boring" is the right answer. This section will get you there.

Monolithic vs Microservices vs SOA — A fair comparison of the three major architectural styles.
Top 10 Software Architecture Patterns — The ten patterns every senior engineer should be able to name and apply.
10 Myths About Microservices — The myths that push teams into microservices for all the wrong reasons.
10 Common Microservices Anti-Patterns — The anti-patterns I see most often in real production codebases.
19 Essential Microservices Patterns — Nineteen patterns worth keeping in active vocabulary.
Essential Software Design Principles (SOLID) — SOLID via real examples instead of canned definitions.
Beginner's Guide to Object-Oriented Programming — An OOP refresher for engineers who came up through other paradigms.
The Ultimate Kubernetes Guide for System Design — Kubernetes from a system design lens, not a DevOps one.
Virtual Machines vs Containers — VMs and containers, explained without the cloud-vendor marketing.
A Beginner's Guide to Distributed Systems — A friendly on-ramp to thinking distributed-first.
Distributed System Design Guide for Beginners — Concepts and patterns for engineers building their first distributed system.
Apache ZooKeeper's Architecture — A look at how ZooKeeper holds distributed state together.
Idempotency 101: Fault-Tolerant Distributed Systems — A production-grade treatment of idempotency in distributed contexts.
How to Use Consistent Hashing in a System Design Interview — Applying consistent hashing live in an interview, walked through.

Misconception #7: "I've memorized 'design Twitter,' I'm fine."

You're not.

The case studies you'll find in this section are not scripts to memorize. They're worked examples of a thinking process — and the goal is to internalize the process, not the answer. If your interviewer asks you to design Twitter and you regurgitate a memorized solution, a sharp interviewer will immediately pivot — "OK, now make it work for live video instead of text" — and you'll be flailing again because you never learned to think, only to recite.

The right way to use this section: read each case study once for ideas, then close the tab and design the same system from scratch on a blank piece of paper. Compare. The gap between your version and mine is your study plan for the next day.

How to Design Instagram — A worked walkthrough of the Instagram design question.
How to Design a Social Media News Feed — Designing a scalable news feed from first principles.
How to Design a URL Shortener Service — The classic URL shortener, solved end to end.
URL Shortener — Dev Community Version — A second take on the same problem from a slightly different angle.
How to Design a Web Crawler — Designing a distributed crawler the way you'd actually build one.
How to Build a Search Engine — How search engines actually get built, from crawler to ranker.
How to Design a Recommendation System — The architecture behind Netflix-style recommendations.
How to Design a Cloud Storage Service — Designing Dropbox or Google Drive, including the parts most writeups skip.
How to Design a Real-Time Chat Application — Designing WhatsApp or Slack from scratch.
How to Design a Real-Time Collaborative Editor — How the Google Docs collaboration model actually works under the hood.
How to Design a Video Conferencing System — The architectural choices behind Zoom-style calls.
How to Design a Ride Sharing Service — Designing Uber end to end without hand-waving over geospatial.
Designing an E-Ticketing System — A ticketing system that survives flash-sale traffic.
Design a Scalable E-Commerce Platform — A modern e-commerce architecture built for scale from day one.
Designing a Parking System — The classic OOD parking lot question, answered properly.
10 Must-Do System Design Interview Questions — My ten must-do questions with full solutions.
64+ System Design Interview Questions — The full canonical question list, grouped by theme.
64 Questions Ranked by Difficulty — The same set, ranked from easiest to hardest.
50 Advanced System Design Questions — Fifty harder questions calibrated for senior and staff loops.

Misconception #8: "An interview is an interview."

Companies vary wildly in what they actually grade.

Google's bar is mostly about depth and rigor — they want you reasoning from first principles and acknowledging what you don't know. Amazon weaves leadership principles through every technical answer. Meta cares about product judgment alongside system judgment, and actually runs two different design rounds depending on the role. Netflix wants pragmatism and ownership. OpenAI is its own beast right now and changes faster than any blog post can keep up with.

If you're prepping with a generic curriculum and then walking into a specific company's loop without tuning, you're leaving offers on the table. Pick your target. Study the rubric.

FAANG System Design Interviews — Strategies from Real Experts — Strategies straight from people who've sat on both sides.
Mastering the FAANG Interview — The complete guide to the entire FAANG loop, not just design.
FAANG Interviews in 2025: What Changed — What shifted in FAANG loops last year and how to adapt your prep.
Google, Amazon, and Meta Compared — How the three biggest companies differ in how they actually run the design round.
Google System Design Interview Questions — Google's favorite questions with sample answers.
Google System Design Secrets — Insider notes on Google's specific scoring habits.
Pass Google System Design as a Non-Programmer — Yes, PMs and TPMs can clear this round — here's the playbook.
Amazon System Design Interview: 5 Sample Questions — Five Amazon-flavored questions worked through.
Amazon System Design Mock Interview Prep — How to run a mock that actually mirrors Amazon's loop.
Amazon Interview Questions: Ultimate Guide — The complete Amazon prep guide, including leadership principles.
Meta System Design Interview Questions — Meta's design questions with structured solutions.
Meta System Design vs Product Design — How to tell Meta's two different design rounds apart.
Mastering Meta's Product Design Interview — A complete guide to Meta's product architecture round.
Mastering the Meta Technical Screen — A thorough walkthrough of Meta's screen for senior candidates.
All You Need to Know About the Meta Interview — A complete overview of Meta's hiring loop.
How to Ace the Meta Engineering Manager Interview — The Meta EM loop, broken down by round.
Netflix System Design Interview Questions — Netflix's design questions with the context they're usually asked in.
Microsoft System Design Interview Questions — Microsoft's rubric and most-asked questions.
OpenAI System Design Interview Questions — The questions to expect when interviewing at OpenAI.
Tesla System Design Interview Questions — How Tesla's design questions diverge from the FAANG mold.
Salesforce System Design Mock Interview — A mock built around Salesforce's actual loop.
Acing the PayPal Software Engineer Interview — A deep dive on PayPal's interview process.

Misconception #9: "Coding and behavioral don't matter for senior roles."

They might matter more.

I have watched far more senior engineers fail FAANG loops on behavioral rounds than on system design. The math is brutal: you can ace four out of five rounds and still get a no-hire because one interviewer didn't believe your "tell me about a time you disagreed with your manager" story. Coding rounds, similarly, do not get easier as you climb the ladder — they get harder, because the bar shifts from "can you solve it" to "can you solve it cleanly while explaining your trade-offs out loud."

This section is the reminder that the design round is one slice of a longer loop, and the candidates who get offers are the ones who prep all of it. Don't skip these because they aren't "the fun part." They're often the part that decides the offer.

Don't Just LeetCode — Follow Coding Patterns — Why pattern-based prep beats raw LeetCode volume every time.
Ultimate Coding Patterns Cheat Sheet — The cheat sheet I hand to every candidate I mentor.
10 Top LeetCode Patterns for FAANG — The ten patterns that unlock most FAANG coding questions.
Top LeetCode Patterns — Dev Community Version — The same breakdown from a slightly different angle.
20 Essential Coding Patterns — Twenty patterns that cover the vast majority of coding interview territory.
5 Essential Algorithms for Coding Interviews — The five algorithms worth committing to memory.
Top 20 Coding Questions for the Google Interview — Twenty Google-favorite coding questions.
10 Coding Interview Mistakes to Avoid — The mistakes I see candidates repeat over and over.
The Ultimate Strategy for Coding Interview Prep — My complete approach to preparing for coding rounds.
Grokking LeetCode — A Smarter Way to Prepare — A smarter alternative to grinding until you drop.
Key Steps to Prepare for a Software Engineer Interview — The core steps to structure your prep from day one.
Software Engineer Interview Preparation: Complete Guide — An end-to-end SE interview prep guide.
The Roadmap to Clearing Technical Interviews in 2025 — A full roadmap for technical interview prep.
12 Weeks Tech Interview Preparation Bootcamp — A structured twelve-week bootcamp plan.
All You Need to Know About an Interview Bootcamp — What to expect from a structured bootcamp and who actually benefits.
Behavioral Interviews at FAANG — What FAANG interviewers are really listening for in behavioral rounds.
FAANG Behavioral Interview Guide — A thorough behavioral prep guide for FAANG loops.
How to Craft Compelling Behavioral Interview Stories — A storytelling framework that turns flat answers into memorable ones.
Culture Fit in Tech Companies — What "culture fit" actually means to hiring committees.
Soft Skills for Software Engineering Interviews — The soft skills that quietly carry the most weight.
Software Engineer Survival Kit 2026 — The skills I'd focus on now to stay relevant through the AI era.
Skills Junior Developers Need in the AI Era — What junior engineers should focus on as the field shifts under them.
Job Hunting in 2025: LinkedIn's 'Open to Work' Badge — Whether the Open to Work badge actually helps your search.
3 Technologies That Will Shape the Future — My take on three technologies quietly reshaping the field right now.

Reference Shelf

A handful of pieces that don't fit cleanly into any single misconception but are worth keeping bookmarked. Cheat sheets, course reviews, recommended papers, tools, and meta-essays on the discipline.

The Ultimate System Design Cheat Sheet (2026) — The current version of the most-saved cheat sheet on the site.
System Design Cheat Sheet for Senior Engineers — A one-page reference tuned specifically for senior-level expectations.
System Design Interview PDF — A downloadable roadmap and checklist for offline prep.
System Design Primer: The Ultimate Guide — A reference primer on every term you'll need to know.
System Design Tutorial for Beginners (2025) — A tutorial that builds intuition through worked examples.
System Design 101 — Beginner's Guide — The absolute first-timer introduction to the vocabulary.
System Design Interview Guide for Beginners — A gentler ramp for engineers with no distributed systems background.
System Design Interview Guide 2025 — A current top-to-bottom guide for FAANG-style design rounds.
Top System Design Interview FAQs — Straight answers to the questions candidates ask me on repeat.
7 Must-Read System Design Papers — The foundational papers every senior candidate should have read.
Top 7 Tools for Creating System Design Diagrams — The diagramming tools I actually use when teaching.
Best System Design Courses for Beginners — A comparison of the entry-level options on the market.
Navigating the Best System Design Courses — How to pick a course that actually matches your level and target.
What Is Grokking the System Design Interview? — A full tour of the flagship course for readers deciding if it fits them.
How to Use Grokking System Design Interview to Ace FAANG — Tactics for getting maximum value out of the course.
Is Grokking the System Design Interview Worth It? — An honest self-review for readers weighing the decision.
Grokking the System Design Interview — 5 Lessons — Five hard-won lessons from years of teaching this material.
HighScalability.com vs DesignGurus.io — A fair comparison of two popular resources and how they complement each other.
Why Practicing System Design Is Crucial — Why this is a long-term career skill, not just interview theater.
Is System Design Important for Data Scientists? — Why data folks should care about system design too.

How to Actually Use This Guide

A few last notes.

One misconception at a time. Don't open all nine sections at once. Pick the one that bites you hardest, work through those articles in sequence, do the exercises in your head as you go, and only then move on. Engineers who spread their attention across all nine misconceptions in parallel make about a third of the progress they'd make working serially.

Practice harder than you read. The single biggest mistake in interview prep is consuming material instead of producing it. After every case study, close the tab and design the same system on paper. After every fundamentals article, try to explain the concept to an imaginary junior engineer in three sentences. Your gaps will show up almost immediately, and they'll be far more useful than another article would have been.

Trust the misconception framing. I organized this post around mistakes rather than topics deliberately. Engineers who frame their prep around weaknesses improve faster than engineers who frame it around coverage. "Read every database article" is a tempting goal because it's measurable, but it doesn't actually correct what's broken in your performance. "I freeze when asked about consistency, so I'm spending three days on Section 2 until I can talk about it cold" — that does.

Come back when you've cleared the loop. I've kept this list updated for years specifically because engineers who land offers write to tell me which articles helped and which were missing. If you make it through and break in, please send me that note. Those messages are why I keep writing this stuff in the first place.

Good luck. You've got this.

DEV Community: Arslan Ahmad

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

Deep Dive 3: What If Redis Goes Down?

Deep Dive 4: Multi-Region

Deep Dive 5: Reducing Load on Redis

What Interviewers Actually Look For

Common Mistakes to Avoid

Key Takeaways

FAQ

Wrapping Up

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

All 20 LeetCode Patterns

The 20 Patterns at a Glance

The Most Common LeetCode Patterns

LeetCode Patterns Cheat Sheet: What the Wording Tells You

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

Which LeetCode Patterns Are Most Important

How This Compares With the Other LeetCode Pattern Lists

Sean Prashad's Leetcode Patterns

AlgoMaster's 15 Patterns

NeetCode

Where this page fits

How to Use This List

FAQs - LeetCode Patterns and Interview Prep

Q1. What are LeetCode patterns?

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

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

Q4. Do LeetCode patterns actually help in real interviews?

Q5. Where can I practice LeetCode patterns?

Q6. Are LeetCode patterns the same as algorithms?

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

Q8. Is mastering patterns enough to crack coding interviews?

Q9. What are the best LeetCode patterns to know?

Q10. Why study coding patterns for interviews?

Q11. How many LeetCode patterns are there?

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

Related questions

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

1. What Are System Design Patterns?

2. Why Patterns Beat Memorizing Architectures

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

Communication Patterns: Moving Data Between Services

Storage and Replication Patterns: Where Truth Lives

Caching Patterns: Serving Data Fast