DEV Community: Gowtham Potureddi

Caching strategies for system design interviews, explained

Gowtham Potureddi — Mon, 19 Oct 2026 17:12:07 +0000

Caching strategies for system design interviews, explained

Almost every system design interview reaches a moment where the database is the bottleneck and someone says "add a cache" — and that is where the real question starts. Caching strategies are not one idea; they are a set of deliberate choices about where a copy of the data lives, who loads it, when it is written, and what happens when it goes stale, and an interviewer can tell in thirty seconds whether you have a vocabulary for those choices or whether "add a cache" is where your thinking stops. A cache trades a little memory and a lot of correctness-anxiety for latency and database offload, and the whole skill is knowing exactly which trade you are making.

The reason this comes up in almost every round is that caching sits on the two axes every design cares about: latency and load. A read served from memory is orders of magnitude faster than one that touches disk, and every read the cache absorbs is one the database never sees. But a cache is a second copy of the truth, and the instant you have two copies you own a consistency problem — the data can be stale, two writers can race, and a key everyone wants can expire at the worst possible moment. This guide walks the choices a strong candidate names out loud: the read strategies (cache-aside and read-through), the write strategies (write-through, write-back and write-around), the eviction policy that decides what to throw away, and the three failures — invalidation, the thundering-herd stampede, and hot keys — that the follow-up questions are really about.

Why caching strategies come up in system design interviews

Caching rarely gets its own whiteboard prompt. It shows up inside another design — a news feed, a product catalogue, a rate limiter, a URL shortener — at the moment you realise the read volume will crush the database. You draw a box labelled "cache," and the interviewer leans in: not whether to cache, but how. Which strategy, what you cache, how you keep it honest, and what happens the moment it fails. Caching is a favourite probe precisely because "add a cache" is the easy half of the sentence and everything true and hard lives in the second half.

The interviewer rarely lets "we'll cache it" stand on its own. "You cache a user's profile, then they update their email. The next read still serves the old address from cache. Walk me through exactly what happened on the write, and what you'd change so the cache and the database don't disagree." That question — consistency between two copies of the truth — is the one a memorised "use Redis" answer can never survive, and the one this topic is really testing.

The rounds on Zynter are modelled on how the loop runs, not scraped from any candidate's recall. What matters for prep is the shape: you name a strategy, and the next sentence out of the interviewer's mouth attacks its weakest point — staleness, write latency, a dropped write, or a stampede.

What the interviewer is really testing

A caching answer is read on the same four dimensions as any design decision. Problem solving — did you pick a strategy that fits the read/write mix, or reach for the first one you remember? Communication — can you say in one sentence why cache-aside tolerates a cache outage but write-back risks losing data? Technical execution — do you handle invalidation on writes, and do you have a concrete fix for a hot key expiring under load? Time management — did you spend your words on the consistency and failure story, not on reciting that Redis is in-memory? Reading this guide teaches the strategies; it does not teach you to defend one while someone pushes on the stale read.

Read strategies: cache-aside and read-through

Start with reads, because that is where a cache earns its keep. The question a read strategy answers is: who is responsible for loading data into the cache on a miss — your application, or the cache itself?

Cache-aside (lazy loading) is the default and the one to reach for first. The application talks to both the cache and the database and owns the logic:

On a read, check the cache. On a hit, return it. On a miss, read from the database, write the value into the cache, and return it.
Only data that is actually requested is ever cached — the cache stays populated with the working set, nothing wasted.
It is resilient: if the cache is down, the application just reads the database and keeps serving. The cache is an optimisation, not a dependency.

Its costs are the two you must name out loud: the first read of any key is always a miss (a cold cache means one slow request per key), and because the application writes the cache separately from the database, the two can drift out of sync unless you invalidate on writes. Cache-aside is what most systems use because the failure mode is graceful — a stale or cold cache degrades latency, not correctness.

Read-through moves the loading logic into the cache layer. The application only ever talks to the cache; on a miss the cache itself fetches from the database, stores the value, and returns it.

The application code is simpler — one place to read from, no miss-handling branch.
The load logic lives in the cache (or a library in front of it), so it is consistent across every caller.
But the cache is now a hard dependency in the read path, and the first-read-miss latency still exists — it just moved.

Say the distinction crisply: cache-aside puts the application in charge and survives a cache outage; read-through hides the database behind the cache for simpler code but makes the cache load-bearing. For most interview designs, cache-aside is the safe default — reach for read-through when you want the loading logic centralised and can accept the cache as a dependency.

Write strategies: write-through, write-back and write-around

Reads decide how the cache fills; writes decide whether it ever lies. The follow-up here is the sharp one — you have the data in two places now; on a write, how do you keep them from disagreeing, and what are you willing to lose? Each strategy answers differently, and the difference is a trade between write latency, consistency, and durability.

Write-through — write the cache and the database together, synchronously, as part of the same operation. The cache is always consistent with the database, so a read right after a write is correct. The cost is write latency: every write pays for both stores, and you may cache data that is never read again.

Write-back (write-behind) — write only the cache, acknowledge immediately, and flush to the database asynchronously (batched, after a delay). Writes are very fast and the database sees far less write load because writes are coalesced. The danger you must state plainly: if the cache node fails before the flush, those writes are lost — this is a durability risk, acceptable for metrics or counters, dangerous for a payment.

Write-around — write straight to the database and skip the cache; the cache fills only later, on a read (via cache-aside). This avoids flooding the cache with data that is written once and rarely read, but a read immediately after a write is a guaranteed miss.

Strategy	On a write	Consistency	Write latency	Risk / best for
Write-through	cache and DB, synchronously	strong — cache matches DB	higher (two writes)	caches write-once-read-never data; safe default when reads follow writes
Write-back	cache now, DB async later	eventual — DB lags the cache	lowest	data loss if the cache dies before flush; best for high-write, loss-tolerant data (counters, metrics)
Write-around	DB only; cache fills on read	DB is the truth; cache may be cold	normal DB write	read-after-write is a miss; best for write-heavy data read rarely

The sentence that scores: write-through buys consistency with write latency, write-back buys speed by risking durability, and write-around keeps write-once data out of the cache — so I'd pair cache-aside reads with write-through for a profile a user edits and reads back, and only reach for write-back where losing a few recent writes is acceptable. Naming the pairing — a read strategy and a write strategy together — is what separates a real answer from "use Redis."

System Design
HLD · Core concept
Pick and defend a caching strategy out loud

Practise on Zynter →

Eviction and the hard problems: invalidation, stampede and hot keys

A cache is finite, so you cannot keep everything — and the moment data lives in two places, keeping them honest becomes the hard part. This section is where most of the follow-ups land, because it is where caches break in production.

Eviction policy decides what to drop when the cache is full. Name the common ones and when each fits:

LRU (least recently used) — evict what has not been touched longest. The sensible default: recently used data is likely to be used again.
LFU (least frequently used) — evict what is accessed least often. Better when popularity is stable over time, but it clings to old favourites and is costlier to track.
FIFO — evict the oldest inserted, regardless of use. Simple, rarely the best fit.
TTL (time to live) — expire entries after a fixed age. Orthogonal to the above and almost always used with them: TTL bounds staleness, LRU bounds size.

Then the three failures the interviewer will push on:

Cache invalidation — the famous hard problem: when the database changes, the cache must not keep serving the old value. The options are to invalidate (delete the key on write, so the next read re-loads it) or update the cache on write (write-through). Deletion is simpler and the usual choice; the trap is the read-modify race, where a stale read repopulates the cache just after a write deleted it. Short TTLs are the backstop that bounds how long any staleness can last.
Cache stampede (thundering herd) — a single very popular key expires, and in the same instant thousands of concurrent requests all miss, all hit the database, and all try to recompute the same value — a self-inflicted load spike that can take the database down. The fixes to name: request coalescing (a lock or single-flight so only one request recomputes while the rest wait for the result), staggered TTLs with jitter (so hot keys do not all expire together), stale-while-revalidate (serve the slightly stale value while one request refreshes it in the background), and pre-warming keys you know will be hot.
Hot keys — one key (a celebrity's profile, a viral post) draws so much traffic it overwhelms the single cache node holding it. The fixes: replicate the hot key across nodes, add a tiny local in-process cache in front of the shared cache, or shard the key's value.

The point to state plainly: eviction keeps the cache small, TTL keeps it fresh, invalidation keeps it honest, and coalescing keeps a miss from becoming an outage. Those are four different jobs and a strong answer names which one each mechanism does.

System Design
HLD · Core concept
Defend your invalidation and stampede plan out loud

Practise on Zynter →

Where caches live: a layered view

"Add a cache" is ambiguous until you say which cache, because caching happens at every layer between the user and the database, and a strong answer places its cache deliberately:

Client / browser cache — the response never leaves the user's device; the cheapest hit of all, controlled by cache headers. Best for static, user-specific data.
CDN / edge cache — static assets and cacheable responses served from a point of presence near the user; absorbs read traffic before it reaches your servers at all.
Application / distributed cache — a shared in-memory store like Redis or Memcached sitting between the app servers and the database. This is the cache most interview discussions mean: it holds the hot working set, is shared across app instances, and is where cache-aside and write-through play out.
Database cache — the database's own buffer pool and query cache. Real, but not something you design; mention it, do not lean on it.

The useful framing: traffic should be absorbed as early as possible — a request served from the browser or CDN is one your application and database never pay for. The distributed cache catches what gets through. Naming the layer you mean, rather than a generic "cache" box, is a small signal that reads as experience.

How to talk about caching in an interview

The probes from every section rhyme. Master these five and you can defend a caching decision in any design, not just this checklist.

"You've added a cache — cache-aside or read-through, and why?" → Cache-aside by default: the app owns the miss logic and the system survives a cache outage because it can still read the database; read-through when I want the load logic centralised and can accept the cache as a dependency. (problem solving)
"On a write, how do you keep the cache and database consistent?" → Invalidate the key on write (delete it so the next read re-loads), or use write-through to update both synchronously; back it with a short TTL so any missed invalidation self-heals, and watch for the read-modify race that repopulates stale data. (communication)
"Write-through, write-back or write-around here?" → Write-through for data read back soon after a write (consistency worth the latency); write-back only where speed matters and losing a few recent writes is acceptable; write-around for write-once, rarely-read data. (technical execution)
"A hot key expires and thousands of reads hit the database at once — what happens?" → A stampede that can take the database down; prevent it with request coalescing so one request recomputes while others wait, staggered TTLs with jitter, and stale-while-revalidate. (technical execution)
"The cache is full — what gets evicted?" → LRU as the default, LFU when popularity is stable, with a TTL layered on to bound staleness regardless of the eviction policy. (problem solving)

Each maps to a debrief dimension. Reading them teaches the answers; it does not teach you to deliver them while someone interrupts with the stale read — that only comes from saying them out loud.

How to prepare: a short plan

You do not need a new topic for every design. You need the caching vocabulary automatic, so when a design hits its read bottleneck you reach for the right pair without thinking.

Day 1: Learn the read strategies (cache-aside vs read-through) and the write strategies (write-through, write-back, write-around) until you can draw each flow and state its one-sentence trade-off from memory.
Day 2: Drill the failures — invalidation on writes, the thundering-herd stampede and its four fixes, and hot keys. These are where the follow-ups live.
Day 3: Place caching inside a real design (a feed, a catalogue, a URL shortener): pick a read strategy and a write strategy together, choose an eviction policy and TTL, and name the layer. Then do it out loud, timed, with someone pushing on the stale read and the hot key.

This explainer feeds the broader Top 25 system design interview questions — caching is a decision inside almost every one of them, so getting it automatic pays off across the whole list.

Frequently asked questions

What is the cache-aside (lazy loading) strategy?

Cache-aside is the most common caching pattern, where the application manages the cache directly. On a read, the application first checks the cache; on a hit it returns the cached value, and on a miss it reads from the database, writes that value into the cache, and returns it. Only data that is actually requested ever gets cached, so the cache naturally holds the working set. Its main advantages are resilience — if the cache goes down, the application simply reads from the database and keeps serving — and efficiency. Its costs are that the first read of any key is always a miss, and that the application must invalidate or update the cache on writes, or the two copies drift out of sync.

Cache-aside vs write-through — what's the difference?

They answer different questions, so they are often used together rather than being alternatives. Cache-aside is a read strategy: it decides how the cache gets populated on a miss (the application loads it). Write-through is a write strategy: it decides what happens on a write (update the cache and the database synchronously so they stay consistent). A very common real-world combination is cache-aside for reads plus write-through or explicit invalidation on writes, so reads are fast and lazily populated while writes keep the cache honest. Confusing the two — treating them as competing options — is a common interview slip.

What is write-back (write-behind) caching and when is it risky?

Write-back caching writes data to the cache and acknowledges the write immediately, then flushes it to the database asynchronously, usually batched after a short delay. This makes writes very fast and greatly reduces write load on the database, because many writes to the same key can be coalesced into one. The risk is durability: if the cache node fails before the pending writes are flushed to the database, those writes are lost permanently. That makes write-back a good fit for high-volume, loss-tolerant data such as counters, metrics or view counts, and a poor fit for data you cannot afford to lose, such as a payment or an order.

How do you handle cache invalidation?

Cache invalidation keeps the cache from serving stale data after the database changes. The two main approaches are to delete the key on a write — so the next read misses and re-loads the fresh value from the database — or to update the cache on the write, as write-through does. Deletion is simpler and the more common choice. A short time-to-live (TTL) is almost always used as a backstop, so that even if an invalidation is missed, any staleness is bounded to the TTL window. The subtle trap is the read-modify race, where a concurrent stale read repopulates the cache just after a write deleted the key; short TTLs and careful ordering reduce its impact.

What is a cache stampede and how do you prevent it?

A cache stampede, or thundering herd, happens when a single popular key expires and thousands of concurrent requests all miss at the same instant, all hit the database, and all try to recompute the same value at once — a self-inflicted load spike that can overwhelm the database. The standard preventions are request coalescing (a lock or single-flight mechanism so only one request recomputes the value while the others wait for the result), staggering TTLs with random jitter so hot keys do not all expire together, serving the slightly stale value while one request refreshes it in the background (stale-while-revalidate), and pre-warming keys you know will be hot before they are needed.

How do I practise a system design interview out loud?

Reading about caching strategies is not the same as defending one while an interviewer pushes on the stale read. On Zynter, the HLD track runs live voice rounds modelled on how real system design loops run — you talk through a design on a shared canvas, and a voice interviewer follows up one question at a time ("on a write, how do the cache and database stay consistent?", "a hot key expires — what happens?"), then gives you a debrief on problem solving, communication, technical execution and time management. The score is a practice signal, not a hiring decision.

Practise it on Zynter

You can recite cache-aside and write-through. The round is won on defending the stale read out loud.

Pick an HLD system design round, add your cache to the design on the canvas, and defend it out loud to a voice interviewer that keeps asking "on a write, how do the cache and database stay consistent?" and "a hot key just expired and ten thousand reads hit the database — what happens?" — then read the debrief. Zynter.ai is on-demand mock interviews modelled on real company loops, with 150+ rounds across 20 companies including the HLD system design track (Sep 2026).

Practise an HLD system design round →
Browse all interview tracks

SQL vs NoSQL: how to actually choose in a system design interview

Gowtham Potureddi — Mon, 19 Oct 2026 15:55:42 +0000

SQL vs NoSQL: how to actually choose in a system design interview

The SQL vs NoSQL question is the one that stalls the middle of a system design interview. You have drawn the boxes, sketched the API, and then the interviewer taps the data store and asks the quiet question: "What database are you using here, and why?" — and a surprising number of strong candidates answer with a preference instead of a reason. They say "I'd use NoSQL, it scales better," or "SQL, it's more reliable," as if one of them simply won the argument years ago. It did not. The honest answer is that SQL and NoSQL are not competitors for the same job — they are different tools whose guarantees fit different workloads, and the whole skill the round is testing is whether you can look at this system's access patterns and pick the store that fits.

That reframe is worth saying out loud early: the question is not "which database is better," it is "which database fits the way this system reads and writes its data." A good system design interview answer treats database design as a decision you derive — from the shape of the data, the consistency the product needs, and the scale it has to reach — not a brand you reach for out of habit. This guide gives you the three things you need to do that on the clock: what a relational (SQL) database actually guarantees, what the four families of NoSQL stores trade those guarantees for, and a requirement-to-choice framework you can walk through out loud while someone pushes back.

Why "SQL or NoSQL?" comes up in every system design interview

Almost every "design a {system}" round reaches a data-model step, and the moment you draw a database box the interviewer wants to know what kind it is. It is a favourite probe because it is a fast, reliable way to tell a memorised answer from real understanding: the candidate who recites "NoSQL scales horizontally" has read a blog; the candidate who says "this is a write-heavy event stream with simple key access and no transactions, so a wide-column store fits, and here's what I give up to get that" has actually thought about the workload. The question is small, but the reasoning behind it is the whole game.

The interviewer rarely accepts a one-word answer. "You said you'd store this in NoSQL — fine, but tell me why, tied to how this system reads and writes, not to which database you like. And what do you lose by not using a relational store here?" That follow-up — justify the store from the access pattern, and name the trade-off — is the one a copied answer can never rehearse, and the one this decision is really testing.

The rounds here are modelled on how the loop runs, not scraped from any candidate's recall. What matters for prep is the shape: you make a database call, and then you have to defend it against "why not the other one?"

What the interviewer is really testing

The score is not "did you pick the database I was thinking of." A good data-store decision reads on four dimensions, and every part of this guide maps to one: problem solving (did you reason from the system's access patterns to a store, instead of defaulting to a favourite), communication (can you say in one sentence why this store fits this workload and name what you trade for it), technical execution (do you actually understand ACID vs eventual consistency, joins, denormalization, sharding and the NoSQL families), and time management (did you make the call quickly and defensibly so the round's minutes go to the harder parts of the design). Reading a comparison table teaches you the facts; it does not teach you to deliver the decision on the clock while someone asks "why not the other one?"

What a relational (SQL) database gives you

Start with the relational store, because it is the sensible default and because naming what it gives you makes the NoSQL trade-offs legible. A SQL database — Postgres, MySQL, SQL Server — stores data in tables with a fixed, enforced schema, and it hands you four things that are genuinely hard to rebuild yourself.

Relational gives you	What it means in the round
A declared schema	Columns and types are defined and enforced; bad data is rejected at write time, so every reader can trust the shape.
Relationships and joins	Data is normalised across tables and recombined at read time with joins, so a fact lives in one place and is never duplicated or left stale.
ACID transactions	A unit of work is atomic, consistent, isolated and durable — debit one row and insert another as all-or-nothing, with strong consistency so a read after a write sees the write.
Ad-hoc queries	You do not have to know the query in advance — filters, aggregations and joins over any column are available, which is priceless while a product's questions are still changing.

The cost is the scaling story. A relational database scales vertically with ease (a bigger machine) and horizontally with read replicas for read-heavy load, but scaling writes beyond one machine means sharding, and once data is split across shards the very things you came for — cross-row joins and multi-row transactions — become hard, because they now cross a network. None of that disqualifies SQL; it just means the honest sentence is: relational is the right default for structured, related data that needs transactions and strong consistency, and it scales a long way before sharding writes becomes the pain point. Money, orders, inventory, bookings — anything where "we lost a write" or "two rows disagree" is unacceptable — starts here.

The NoSQL families — and what each one trades

The first mistake to avoid out loud is treating NoSQL as one thing. It is an umbrella over four quite different families, each optimised for a different access pattern. Name the family, not just "NoSQL," and you have already shown you understand the space.

Family	Optimised for	Example stores	Reach for it when
Key-value	O(1) get/put by a single key	Redis, DynamoDB	sessions, caches, feature flags, rate-limit counters — you always look up by one key
Document	self-contained JSON-like documents, flexible schema	MongoDB, Couchbase	catalogs, user profiles, content — the record is read and written as a whole and the shape varies
Wide-column	enormous write throughput, partition + clustering keys	Cassandra, HBase, Bigtable	event streams, time-series, messaging history — write-heavy, queried by a known key range
Graph	traversing relationships (edges) fast	Neo4j, Neptune	social graphs, recommendations, fraud rings — the questions are about connections

Under the four families runs one common thread, and it is the sentence that scores: NoSQL stores buy horizontal scale-out, a flexible or absent schema, and predictable low-latency access by giving up some of what relational guarantees — usually strong consistency (many default to eventual consistency, the "BASE" posture rather than ACID, though several now offer stronger options), joins, and multi-row transactions. Because there are no joins, you denormalize: you duplicate data across records so each query reads from one place. The governing rule, worth stating plainly, is the inversion of the relational mindset — in NoSQL you design the data around the queries, not the queries around the data. That is the real cost and the real power: you must know your access patterns up front, and in exchange you get a store that scales those patterns almost linearly.

System Design
HLD · Core concept
Defend a SQL-vs-NoSQL call out loud, with follow-ups

Practise on Zynter →

How to choose: a decision framework

Now the part the round is actually scoring — turning the two toolkits into a decision. The move is to refuse the "which is better" framing and answer by requirement. Ask three questions of the data and let the answers point at a store.

If the system needs…	Lean toward	Because
multi-row transactions, strong consistency, rich relationships	Relational (SQL)	ACID and joins are built in; correctness beats raw write scale here (payments, orders, inventory, bookings)
massive write volume, simple key-based access, horizontal scale from day one	NoSQL — pick the family by access pattern	scale-out and low-latency key access without the sharding pain of SQL (feeds, events, sessions, metrics, large catalogs)
fast traversal of connections (friends-of-friends, paths)	Graph	relationship queries that would be many self-joins in SQL become native traversals
unknown or shifting access patterns, heavy ad-hoc reporting	Relational (SQL)	you can ask new questions without re-modelling; NoSQL punishes queries you didn't design for

Then say the thing that shows range: most real systems are polyglot. A payments product keeps its ledger in a relational store for transactions, caches hot reads in a key-value store, and streams its audit events into a wide-column store — three databases, each chosen for one access pattern, not one database forced to do everything. Reaching for "I'd use a relational store for the transactional core and a key-value cache in front of it" is almost always a stronger answer than picking a single winner.

One honest nuance keeps you out of trouble: the line between the two has blurred. Modern relational databases and NewSQL systems (CockroachDB, Spanner) scale horizontally, and several NoSQL stores now offer transactions and tunable consistency. So do not over-claim — "NoSQL can't do transactions" or "SQL can't scale" are both out of date. The durable skill, and the one the interviewer is grading, is reasoning from access patterns to a store and naming the trade-off, which survives whatever any single product adds next quarter.

System Design
HLD · Core concept
Walk the data-model step of an HLD round out loud

Practise on Zynter →

A worked example out loud

Put the framework to work on a system with two very different stores inside it, because that is what interviewers like to hand you. Say you are designing an e-commerce app, and the interviewer asks where two things live: the orders and the activity feed.

For orders, reason out loud: an order touches several related entities — a customer, line items, a payment, inventory — and it must be transactional (take payment, decrement stock and create the order as all-or-nothing) and strongly consistent (a customer who just paid must see their order). That is a textbook relational workload: a SQL store, normalised across tables, with an ACID transaction around the checkout. Write volume is moderate and correctness is non-negotiable, so the relational guarantees are exactly what you want and sharding writes is a problem for much later.

For the activity feed — every view, click and add-to-cart streaming in — the shape is the opposite: a firehose of simple, append-only events, queried by user or by time range, with no transactions and no joins, and it has to absorb bursts and scale horizontally from the start. Losing one feed event is survivable; losing an order is not. That is a wide-column NoSQL workload (Cassandra-style), partitioned by user id, denormalized so each read hits one partition. Two stores, one system, each chosen from its access pattern — and now you can name the polyglot design instead of forcing both into one database. That contrast, reasoned aloud, is worth more than any single "right" answer.

"Your relational database can't keep up with the write volume anymore — what do you do before you rip it out for NoSQL?" First, the cheap wins: add read replicas to offload reads, put a cache in front of hot queries, and batch or queue writes to smooth bursts. Then vertical scale, then functional partitioning (move a heavy table to its own database). Only when writes genuinely exceed one machine's ceiling do you shard — and at that point, if the workload is simple key-based access without cross-row transactions, a NoSQL store that shards natively may be less painful than sharding the relational one by hand. The point: migrating stores is the last lever, not the first.

How to answer "SQL or NoSQL?" in an interview

Scan the probes and they rhyme. Master these five and you can defend a database call for a system drawn differently from any here.

"Why this store, and not the other one?" → Name the access pattern first (transactional-and-related vs write-heavy-simple-key vs traversal), then the store that fits it, then the one thing you trade. Never lead with a brand preference. (problem solving)
"What do you give up by choosing NoSQL here?" → Usually joins, multi-row transactions and strong consistency; you denormalize and design the data around the queries, so access patterns you didn't plan for become expensive. (communication)
"Are NoSQL databases ACID or not?" → Classically BASE / eventually consistent, favouring availability and scale; but several (DynamoDB, MongoDB) now offer transactions and tunable consistency, so say "it depends on the store and the configuration," not a blanket no. (technical execution)
"Your SQL database is overloaded on writes — now what?" → Replicas and caching for reads first, then vertical scale and functional partitioning, then sharding; switching to NoSQL is the last resort, justified only when the workload is simple-key and truly beyond one machine. (problem solving)
"Would you really use two databases in one system?" → Yes — polyglot persistence is normal: a relational core for the transactional data plus key-value/wide-column stores for caching and scale-out, each chosen for one access pattern. (technical execution)

Each maps to a debrief dimension. Reading this list teaches you the answers; it does not teach you to deliver them while someone interrupts — that only comes from saying them out loud.

How to prepare: a short plan

You do not need to memorise a feature matrix. You need the guarantees and the framework automatic, so the data-model step of any design is a quick, defensible call instead of a stall.

Day 1: Learn what relational gives you (schema, joins, ACID, ad-hoc queries) and its scaling story (vertical, replicas, sharding-with-effort). Say, in one sentence each, when it is the right default.
Day 2: Learn the four NoSQL families and one example store and use-case for each, plus the common trade-off (horizontal scale + flexible schema vs eventual consistency + limited joins) and the "design around the queries" rule.
Day 3: Drill the decision framework — take five systems (a URL shortener, a chat app, a payments ledger, a social feed, a recommendations engine) and reason each to a store (or a polyglot mix) out loud, naming the trade-off.
Day 4: Do the data-model step of a couple of full HLD rounds against the clock, narrating the choice and defending it against "why not the other one?" This is the rep that counts.

This post is one of the concept pages behind the broader system design interview questions track — once the SQL-vs-NoSQL call is reflex, it stops eating the minutes you need for the rest of the design.

Frequently asked questions

What is the difference between SQL and NoSQL in one sentence?

SQL (relational) databases store data in tables with a fixed, enforced schema and give you relationships, joins, ACID transactions and strong consistency, which makes them the right default for structured, related data that must stay correct; NoSQL is an umbrella over key-value, document, wide-column and graph stores that trade some of those guarantees — often joins, multi-row transactions and strong consistency — for a flexible schema, horizontal scale-out and predictable low-latency access to the specific patterns you designed for. The one-liner: SQL fits transactional, related data; NoSQL fits a known access pattern that needs to scale horizontally.

When should I use NoSQL instead of SQL?

Reach for NoSQL when the workload has a simple, known access pattern that needs to scale horizontally from the start — massive write volume, key-based lookups, flexible or evolving record shapes — and does not need multi-row transactions or joins. Event streams, activity feeds, session stores, caches, metrics and very large catalogs are classic fits, and you pick the family by the access pattern (key-value for pure lookups, document for whole-record reads, wide-column for write-heavy time-series, graph for relationship traversal). If the data is highly related and needs transactions and strong consistency, or if the queries are still changing and you need ad-hoc reporting, prefer SQL.

Are NoSQL databases ACID or eventually consistent?

Classically, NoSQL stores favour the BASE model — basically available, soft state, eventually consistent — trading strong consistency for availability and horizontal scale, which is why "eventual consistency" is the stereotype. But it is no longer a clean split: several NoSQL databases now offer transactions and tunable or strong consistency (DynamoDB supports transactions, MongoDB supports multi-document transactions, and systems like Spanner and CockroachDB give distributed ACID). So the accurate interview answer is "it depends on the store and how you configure it," not a blanket "NoSQL isn't ACID."

Can you use both SQL and NoSQL in the same system?

Yes, and it is the normal design at scale — it is called polyglot persistence. You pick a store per access pattern rather than forcing one database to do everything: a relational store for the transactional core (orders, payments), a key-value store for caching and sessions, a wide-column store for high-volume event or time-series data, and perhaps a graph store for relationship-heavy features. Saying this in an interview signals maturity, because it shows you treat the database as a per-workload decision instead of a single religious choice.

Does NoSQL really scale better than SQL?

Not universally — it scales differently. NoSQL stores are built to scale writes horizontally across many nodes out of the box, which is genuinely easier than sharding a relational database by hand, so for write-heavy, simple-key workloads they scale more cheaply. But relational databases scale a long way with vertical hardware, read replicas and caching, and modern NewSQL systems scale horizontally too. The honest statement is that NoSQL makes horizontal write scaling easy by giving up joins and transactions; SQL makes correctness and flexible querying easy and needs more effort to scale writes. Match the strength to the workload.

How do I practise answering SQL vs NoSQL out loud?

Reading a comparison is not the same as defending a database call while someone asks "why not the other one?" On Zynter, the HLD track runs live voice rounds modelled on how real system design loops run — you draw the design on a shared canvas, reach the data-model step, and a voice interviewer pushes with the follow-ups above one at a time, then gives you a debrief on problem solving, communication, technical execution and time management. The score is a practice signal, not a hiring decision.

Practise it on Zynter

You can recite the comparison table. The round is won on reasoning to a store out loud.

Pick any system design round, draw it on the canvas, and when you reach the database box defend your SQL-or-NoSQL call to a voice interviewer that keeps asking "why this store, not the other one?" and "what do you give up here?" — then read the debrief. Zynter.ai is on-demand mock interviews modelled on real company loops, with 150+ rounds across 20 companies including the HLD system design track (Sep 2026).

Practise an HLD round →
Browse all interview tracks

Database sharding and partitioning: the scaling move an interviewer makes you justify

Gowtham Potureddi — Mon, 19 Oct 2026 15:53:03 +0000

Database sharding and partitioning: the scaling move an interviewer makes you justify

Every system design answer eventually hits the same wall: one database is not enough. The moment your design has to hold more data or absorb more writes than a single machine can, database sharding stops being a buzzword and becomes the thing you have to reason about out loud. And sharding and partitioning are where an interviewer separates the candidates who scale a database by reflex — "we'll just shard it" — from the ones who can say why now, on what key, and at what cost. This explainer is about being the second kind.

The reason this comes up in almost every system design interview is that the trick everyone reaches for first — add read replicas — only scales reads. The instant the bottleneck is write throughput or raw storage, replicas do nothing, and the only way out is horizontal scaling: split the data across many machines so no single one carries it all. That split is partitioning, sharding is partitioning taken across machines, and the quality of your answer is decided by the one decision underneath it — the shard key. Get the vocabulary straight, learn the three ways to split the data, and learn to pick and defend a shard key, and you have the whole topic.

Why sharding comes up in every system design interview

Nearly every "design X" round reaches a point where you have drawn a single database box and the interviewer asks the quiet question that decides the second half of the round: what happens when this one box isn't enough? A single database server has a ceiling — CPU, memory, disk, and the number of open connections — and once your writes or your dataset cross it, no amount of query tuning or caching moves the ceiling. Read replicas buy you read capacity and nothing else: every replica still has to apply every write, so the write and storage ceiling is unchanged. Sharding is the answer the interviewer is waiting to hear, and then to pressure-test.

"Your users table is 10 TB and growing, and one box can't hold it or keep up with the writes. How do you shard it, and on what key?" That question is the whole topic in one line — it is not enough to say "shard by user"; you have to justify the key against how the data is read and written, and name what you give up.

The rounds here are modelled on how the loop runs, not scraped from any candidate's recall. What matters for prep is the shape: you introduce sharding at the right moment, name a strategy, defend a shard key, and then answer the follow-up about the shard that runs hot — out loud, while someone pushes back.

What the interviewer is really testing

The score is not "did you say the word sharding." A good system design debrief reads on four dimensions, and every move in this topic maps to one: problem solving (did you recognise the moment a single DB and its replicas are exhausted, and reach for the strategy that fits the access pattern), communication (can you justify the shard key in one sentence — high cardinality, even distribution, aligned with the dominant query — and name the trade-off you accept), technical execution (range vs hash vs directory, consistent hashing to bound remaps, scatter-gather and two-phase commit for cross-shard work), and time management (did you introduce sharding when it was needed rather than as your first move, and avoid rat-holing on resharding mechanics unless pushed). Reading this teaches the ideas; it does not teach you to deliver them on the clock.

Partitioning vs sharding: vertical and horizontal

Start by getting the words right, because interviewers notice when they are used loosely. Partitioning is the general act of splitting one logical dataset into smaller parts. It comes in two flavours.

Vertical partitioning splits by column or feature — you move some columns, or whole tables, into their own store. A user's profile fields live in one place, their billing records in another, their activity log in a third. Each store holds different columns for the same entities. This is how a monolith's database naturally breaks apart as it grows into services.
Horizontal partitioning splits by row — every partition has the same schema but holds a different subset of the rows. Users 1–1,000,000 here, users 1,000,001–2,000,000 there. Each partition is a complete, self-contained slice of the table.

Sharding is horizontal partitioning where the partitions live on separate machines. Each shard is its own database, on its own hardware, holding its slice of the rows. That distinction is the point: splitting rows into logical partitions on one server buys you nothing against a capacity ceiling; spreading those partitions across machines is what adds CPU, memory, disk and connections.

The sentence that earns points: "Read replicas scale reads because every replica is a full copy; they do nothing for write throughput or storage, because each still applies every write and holds all the data. Sharding is the only thing that scales writes and storage, because each shard owns just its slice." Say that and you have explained not only what sharding is but exactly when it is the right tool.

Sharding strategies: range, hash and directory

Once you have decided to shard, the next question is how do you decide which row goes to which shard? There are three classic strategies, and naming all three before picking one signals range.

	Range-based	Hash-based	Directory / lookup-based
How	assign contiguous key ranges to shards (A–F, G–M, …)	shard = a function of `hash(shard_key)`	a lookup table maps each key (or key range) to a shard
Range scans	cheap and local — a range lives on one shard	expensive — a range is scattered across all shards	depends on how the table is organised
Load spread	risks hotspots — sequential keys (timestamps, auto-increment ids) all land on the newest shard	even — hashing scatters adjacent keys	even or uneven, you control it by editing the map
Adding a shard	split a range; moves one range's data	plain `hash mod N` remaps almost everything — use consistent hashing	edit the directory; move only what you choose
Main cost	hotspot management	lost locality; needs consistent hashing	the directory is an extra dependency and a potential single point of failure / bottleneck

A few things to say out loud about each. Range-based sharding keeps range queries fast because a whole range sits on one shard, which is why time-series and ordered data often use it — but that same property is its trap: if your key increases monotonically, every new write targets the last shard and you have built a hotspot. Hash-based sharding fixes the spread by scattering adjacent keys everywhere, at the price of range scans (a "last 7 days" query now hits every shard); and the naive version, hash(key) mod N, is a trap of its own, because changing N when you add a shard remaps almost every key at once — which is exactly the problem consistent hashing solves by moving only a small fraction of keys when the shard count changes. Directory-based sharding is the most flexible — you rebalance by editing a mapping table — but that table is now something every query consults, so it has to be small, cached, and highly available, or it becomes the bottleneck you were trying to escape.

System Design
HLD · Core concept
Pick a sharding strategy and defend it out loud

Practise on Zynter →

Choosing a shard key — and the problems sharding creates

The strategy matters, but the decision that actually makes or breaks a sharded design is the shard key — the column (or combination of columns) whose value decides which shard a row lives on. A good shard key has three properties, and you should name them:

High cardinality — many distinct values, so the data can be divided finely. Sharding on a boolean or a status column gives you at most a handful of buckets and no room to grow.
Even access distribution — traffic spreads roughly equally across values, so no shard carries far more than its share.
Aligned with the dominant query — most reads and writes should be answerable from a single shard. If you shard orders by order_id but almost every query is "all orders for this customer," you have guaranteed that the common path touches every shard.

When a key fails the even-distribution test, you get the hotspot — often called the celebrity problem. Shard a social graph by user and most users are fine, but the one account with fifty million followers sends its shard into the ground while the others idle. The fixes are worth naming: a compound shard key (combine the hot dimension with another, e.g. user plus time bucket) to spread one entity's load, splitting the hot key's data across shards deliberately, or putting a cache in front of the hot key so most reads never reach the shard.

"One of your shards is running 5x hotter than the rest. What did you get wrong, and how do you fix it without taking the system down?" The honest answer names the shard key: it concentrated load — a low-cardinality or skewed key, or a celebrity entity. The fix is a better or compound key and a controlled migration of the hot data to rebalance, done online by double-writing and backfilling rather than with a maintenance window. Admitting the key was the mistake scores better than pretending the strategy was fine.

Sharding also creates costs that did not exist on one machine, and a strong answer volunteers them before being asked. Cross-shard joins and cross-shard transactions are the big ones. A query that spans shards becomes a scatter-gather — fan the request to every shard, then merge the results in the application — which is slower and harder to paginate and rank. A transaction that must update rows on two shards can no longer rely on the database's single-node ACID guarantee; you reach for two-phase commit (correct but slow and prone to blocking) or a saga (a sequence of local transactions with compensating undo steps). The standard advice, and the thing to say, is: design the shard key so the common path stays single-shard, and avoid cross-shard transactions wherever you can. Finally, there is resharding — changing the number of shards or the key when you outgrow the layout — which is painful enough that it is the reason to choose a scheme (consistent hashing, a generous number of virtual shards up front) that minimises how much data moves when you grow.

System Design
HLD · Core concept
Choose a shard key and survive the hotspot follow-up

Practise on Zynter →

Sharding in a system design interview

The thing that separates a clean answer from a muddled one is timing. Do not reach for sharding first. The ordered path an interviewer wants to hear is: a single primary, then read replicas when reads dominate, then caching to absorb the hot reads, and only when writes or storage still exceed one machine do you shard. Introducing sharding at that moment — and saying explicitly "replicas and cache won't help here because the bottleneck is write throughput, so I'll shard" — is the signal that you are reasoning, not reciting. Then name the key, justify it against the access pattern in one sentence, call out the hotspot risk, and state how you will handle the queries that have to cross shards.

Scan the probes that follow, because they rhyme across every round:

"When do you shard instead of adding replicas?" → When the bottleneck is write throughput or storage, not reads. Replicas copy the whole dataset and apply every write, so they scale reads only; sharding is the only thing that splits writes and storage across machines. (problem solving)
"Range, hash or directory — which and why?" → Range when range scans dominate and you can manage the sequential-write hotspot; hash (with consistent hashing) when you need even load and can live without cheap range scans; directory when you need flexible rebalancing and can keep the lookup table fast and highly available. (technical execution)
"What makes a good shard key?" → High cardinality, even access distribution, and alignment with the dominant query so the common path stays single-shard. (communication)
"One shard is a hotspot — what happened and how do you fix it?" → The key concentrated load; fix with a compound key, splitting the hot entity, or caching in front, and rebalance online. (problem solving)
"A query has to span shards — how?" → Scatter-gather and merge in the application for reads; for writes across shards, avoid it, or use two-phase commit or a saga, accepting the latency and complexity cost. (technical execution)

Each maps to a debrief dimension. Reading the list teaches you the answers; it does not teach you to deliver them while someone interrupts — that only comes from saying them out loud.

How to prepare: a short plan

You do not need to memorise a database internals textbook. You need these ideas automatic so the next "design X" round, when it reaches the single-database wall, is just the same reasoning with new nouns.

Day 1: Lock the vocabulary — vertical vs horizontal partitioning, and why sharding (horizontal across machines) is the only thing that scales writes and storage. Say the replicas-vs-sharding sentence until it is reflex.
Day 2: Drill the three strategies out loud — range, hash (with consistent hashing), directory — and when you would pick each, in one sentence apiece.
Day 3: Own the shard key — the three properties, the hotspot/celebrity problem and its fixes, and the cross-shard join/transaction and resharding costs. Practise volunteering the costs before you are asked.
Day 4: A timed HLD round where you reach the sharding moment and defend a shard key against follow-ups, narrating the whole way, with someone (or something) pushing back.

This explainer backs one row of the broader system design interview prep map — once sharding is automatic, the same reasoning carries the key-value store, the CDN and the analytics rounds that all lean on it.

Frequently asked questions

What is the difference between sharding and partitioning?

Partitioning is the general idea of splitting one dataset into smaller parts; sharding is a specific kind of partitioning. Partitioning comes in two forms: vertical, which splits a table by column or feature (profile fields in one store, billing in another), and horizontal, which splits a table by row into subsets that share the same schema. Sharding is horizontal partitioning carried across separate machines — each shard is its own database on its own hardware holding a slice of the rows. The practical point is that logical partitioning on one server does not raise a capacity ceiling, whereas sharding across machines adds CPU, memory, disk and connections, which is why sharding is what scales writes and storage.

What is a shard key and why does it matter so much?

A shard key is the column or combination of columns whose value decides which shard a row belongs to. It matters more than the sharding strategy because it determines how evenly load spreads and whether your common queries stay on one shard. A good shard key has high cardinality (many distinct values so data divides finely), even access distribution (no value attracts far more traffic than others), and alignment with the dominant query (most reads and writes answerable from a single shard). A poor key concentrates traffic on one shard or forces most queries to fan out across all of them, and because changing the key later means resharding, it is a decision you want to get right up front.

Range-based vs hash-based sharding — when do I use each?

Use range-based sharding when range scans dominate your workload, because a contiguous range of keys lives on a single shard and those queries stay local; the risk is that monotonically increasing keys like timestamps or auto-increment ids send every new write to the newest shard and create a hotspot. Use hash-based sharding when you need even load distribution and can live without cheap range scans, because hashing scatters adjacent keys across all shards; pair it with consistent hashing so that adding or removing a shard moves only a small fraction of keys instead of remapping everything, which naive hash mod N would do.

What is the hotspot or celebrity problem in sharding?

A hotspot is a single shard that receives far more traffic than the others, usually because the shard key concentrates load. The classic case is the celebrity problem: shard a social platform by user and most users are evenly spread, but one account with tens of millions of followers overwhelms its shard while the rest idle. The same happens with low-cardinality keys or sequential keys under range sharding. Fixes include a compound shard key that combines the hot dimension with another (such as user plus a time bucket), deliberately splitting the hot entity's data across shards, and placing a cache in front of the hot key so most reads never reach the shard.

How do queries work when the data spans multiple shards?

A read that spans shards becomes a scatter-gather: the application fans the request out to every relevant shard, each returns its local result, and the application merges, sorts and paginates them — slower and more complex than a single-shard query, which is why you try to design the shard key so the common path stays on one shard. A write or transaction that spans shards can no longer rely on a single database's ACID guarantee, so you either avoid it, use two-phase commit (correct but slow and prone to blocking), or use a saga, which is a sequence of local transactions with compensating actions to undo on failure. The general rule is to keep the frequent path single-shard and treat cross-shard operations as the expensive exception.

How do I practise sharding questions out loud?

Reading about sharding is not the same as defending a shard key while someone asks why one shard is on fire. On Zynter, the high-level design track runs live voice rounds modelled on how real system design loops run — you draw the architecture on a shared canvas, reach the single-database wall, and a voice interviewer pushes with the follow-ups above one at a time, then gives you a debrief on problem solving, communication, technical execution, and time management. The score is a practice signal, not a hiring decision.

Practise it on Zynter

You can read what a shard key is. The round is won on defending the one you chose out loud.

Pick a high-level design round, scale it past the single-database wall on the canvas, and defend your shard key to a voice interviewer that keeps asking "on what key, and why?" and "one shard is 5x hotter than the rest — what went wrong?" — then read the debrief. Zynter.ai is on-demand mock interviews modelled on real company loops, with 150+ rounds across 20 companies including the HLD system design track (Sep 2026).

Practise an HLD round →
Browse all interview tracks

CAP theorem explained: the system design interview concept, done precisely

Gowtham Potureddi — Mon, 19 Oct 2026 15:47:57 +0000

CAP theorem explained: the system design interview concept, done precisely

The CAP theorem is the single most quoted — and most misquoted — idea in a system design interview. State it as "pick two of consistency, availability and partition tolerance" and a good interviewer will immediately push back, because that framing is wrong in a way that decides whether you actually understand distributed systems or just memorised a triangle. CAP is not a menu of three you choose two from; it is a statement about what happens to a replicated datastore at the one moment its network breaks, and the whole value of the idea is the choice it forces on you at that moment.

Here is the version that survives follow-ups. In any system that keeps copies of data on more than one machine, the network will eventually drop or delay messages between those machines — a partition. You do not get to opt out of that; partitions happen whether you planned for them or not. So the real question CAP answers is: when a partition is happening, and a request arrives at a node that cannot reach the others, do you answer it anyway with possibly-stale data, or do you refuse to answer until you can guarantee it is correct? Answer anyway and you chose availability; refuse until correct and you chose consistency. That is the entire theorem, and reaching it in one breath — partitions are not optional, so the choice is consistency versus availability during a partition — is what the round is testing. This guide walks the three properties precisely, the trade-off they really force, how real databases land on each side, and how to use CAP to justify a design decision out loud instead of reciting it.

Why the CAP theorem comes up in system design interviews

CAP surfaces the moment your design has more than one copy of the data — which is almost always. Add a read replica, shard a database, put a cache in front of it, replicate across regions, and you have a distributed datastore whose nodes can lose contact with each other. So any time you say "I'll replicate this for availability" or "I'll use Cassandra here" or "the write goes to the primary and fans out to the followers," you have made a CAP decision, and the interviewer will ask you to defend it.

"Your database cluster is replicated across two data centres, and the link between them goes down for thirty seconds. A write request lands on the side that can't reach the other — do you accept the write and answer, or reject it until the link is back? Pick one, and tell me what the user sees either way."

That question is the whole point. It cannot be answered by naming the theorem; it is answered by knowing that you must choose, picking a side for this specific data, and naming the cost the user pays. The system design rounds here are modelled on how the loop runs, not scraped from any candidate's recall — what matters for prep is the shape: a decision under a partition, and a follow-up that makes you own the consequence.

What the interviewer is really testing

The score is not whether you can recite "consistency, availability, partition tolerance." A good debrief reads on four dimensions, and CAP touches each: problem solving (did you recognise that partition tolerance is forced, so the real axis is C versus A), communication (can you say in one sentence why this data tolerates staleness, or why it cannot), technical execution (can you map the choice onto a real datastore and its replication/quorum behaviour), and time management (did you make the call quickly and move on, instead of drawing the triangle for five minutes). Reading the theorem teaches you the words; it does not teach you to make the call out loud while someone presses on the consequence.

The three properties, precisely

Most wrong answers start with a loose definition, so pin each term down — the precision is where the points are.

Property	What it actually means	Common misreading
Consistency (C)	Every read returns the most recent write (or an error). Every node shows the same data at the same logical instant — linearizability, a single up-to-date copy as far as any client can tell.	It is not the "C" in ACID (which is about database invariants and constraints). CAP's C is about reads agreeing across replicas.
Availability (A)	Every request to a non-failing node receives a non-error response — the system always answers, though the answer may be stale.	Not "the system is up most of the time." It is a strict guarantee: every request gets an answer, even during a partition.
Partition tolerance (P)	The system keeps operating even when the network drops or arbitrarily delays messages between nodes.	Not a feature you can bolt on or leave off — in any multi-node system, partitions are a fact of the physical world.

The definition that earns the point is consistency: CAP consistency is linearizability, not the ACID "C." Say that out loud and the interviewer knows you have read past the triangle. The other subtlety is availability — it is an absolute: a system is available under CAP only if it answers every request even while partitioned, which is a much stronger claim than "high uptime."

The real trade-off: CP vs AP during a partition

Now the correction that the whole round turns on. The "pick two of three" phrasing implies three symmetric options — CA, CP, AP — as if you freely choose any pair. You do not, because partition tolerance is not negotiable. Networks partition: cables are cut, switches fail, a data-centre link saturates, a GC pause makes a node look dead. If your data lives on more than one machine, partitions will happen, so P is mandatory. That collapses the three choices into one real axis.

So the honest statement of CAP is this: when a partition occurs, you must sacrifice either consistency or availability — you cannot keep both. Consider the request that lands on a node cut off from its peers:

CP (consistency over availability): the node refuses to answer — it returns an error or blocks — because it cannot guarantee it has the latest write. Data stays correct everywhere; some requests fail during the partition. You chose consistency and gave up availability on the minority side.
AP (availability over consistency): the node answers anyway from its local copy, which may be stale, and the replicas reconcile later (eventual consistency). Every request gets an answer; some answers are briefly wrong. You chose availability and gave up strong consistency.

"CA" is the one that does not really exist in a distributed system. A CA system is one that assumes partitions never happen — which is only true of a single node (no network between replicas to partition). The moment you have two nodes, the network can split them, and you are forced back onto the CP-versus-AP axis. So in practice CAP is a binary choice made per partition: refuse and stay correct, or answer and risk staleness.

"During the partition, the CP system makes the user see an error on the cut-off side; the AP system makes the user see slightly old data. Which failure is acceptable for this feature? A bank balance transfer wants CP — better to fail the write than double-spend. A social feed's like count wants AP — better to show a stale count than a spinner."

System Design
HLD · Core concept
Defend a CP-vs-AP choice out loud, with follow-ups

Practise on Zynter →

CP vs AP in practice, and why PACELC completes the picture

Naming real systems shows you have used this, not just read it — but say the caveat too, because most "AP" and "CP" databases are tunable, so the label is a default, not a law.

Leaning	Example systems	Default behaviour during a partition
CP (consistency first)	HBase, MongoDB (default/majority), etcd, ZooKeeper, Spanner	The minority/unreachable side stops serving affected requests; a leader or quorum must be reachable before a write or consistent read succeeds.
AP (availability first)	Cassandra, DynamoDB, Riak, Couchbase	Every reachable node keeps answering from its replica; writes are accepted on both sides and reconciled afterwards (eventual consistency, last-write-wins or CRDT-style merges).
Tunable (per request)	Cassandra / DynamoDB quorum levels	Consistency is a knob: require more replicas to agree (towards CP) or fewer (towards AP) per read/write. `R + W > N` buys you read-your-writes.

The honest add-on that impresses: CAP only describes the partition case, and partitions are rare. What about the 99.9% of the time the network is fine? That is what PACELC captures: if Partition (P), choose Availability or Consistency (A/C); Else (E), choose Latency or Consistency (L/C). In other words, even with a healthy network there is a standing trade-off — synchronous replication for strong consistency costs latency, asynchronous replication for low latency costs consistency. So a full answer sounds like: "This is PC/EL — consistent when partitioned, but tuned for low latency the rest of the time." PACELC is the model that explains why DynamoDB feels fast (EL) and Spanner feels strict (EC) even when nothing is broken.

System Design
HLD · Core concept
Classify a datastore as CP or AP and justify it

Practise on Zynter →

How to use the CAP theorem in a system design interview

The mistake is reciting CAP as trivia. The move that scores is wielding it as a decision tool: when you pick a datastore or a replication scheme, say which side of the partition line it sits on and why this data can live with that. Master these five and you are ready for any version of the follow-up.

"Can't you just have all three?" → No. Partitions are a fact of networks, so P is mandatory in any multi-node system; that forces a choice between C and A during a partition. "CA" only describes a single node that can't be partitioned. (problem solving)
"CP or AP for this feature — which and why?" → Tie it to the data: strong-consistency-critical state (payments, inventory, unique usernames) is CP — fail rather than serve wrong; staleness-tolerant state (feeds, counts, product catalogues) is AP — answer rather than stall. (communication)
"What does the user actually see during the partition?" → With CP, errors or timeouts on the cut-off side until it heals; with AP, slightly stale reads and conflicts that reconcile afterwards. Name the concrete symptom, not just the label. (technical execution)
"Which real database, and is it really always that?" → Name one (Cassandra = AP, HBase/ZooKeeper = CP) and immediately add that many are tunable per request via quorum (R + W > N), so the label is a default. (technical execution)
"What about when the network is fine?" → Reach for PACELC: even without a partition there's a latency-versus-consistency choice, so describe the system as PC/EL or PA/EC to show you think beyond the failure case. (problem solving)

Each maps to a debrief dimension. Reading this list teaches you the answers; it does not teach you to deliver them while someone keeps asking "but what does the user see?" — that only comes from saying them out loud.

How to prepare: a short plan

You do not need to memorise a taxonomy. You need the reframe automatic and one or two real systems in each camp so the choice is reflex.

Day 1: Learn the three definitions precisely — especially that CAP consistency is linearizability, not ACID's C, and that availability is an absolute per-request guarantee. Write each in one sentence.
Day 2: Internalise the reframe: P is mandatory, so the real choice is C versus A during a partition, and CA is a single-node fantasy. Be able to say the whole theorem in two sentences.
Day 3: Map real stores — Cassandra/DynamoDB (AP, tunable), HBase/ZooKeeper/etcd (CP) — and learn PACELC so you can describe a system when the network is healthy too.
Day 4: Drill the application: for ten features (bank transfer, like count, shopping cart, username registration, DNS, chat delivery), say CP or AP and why in one sentence, out loud, then answer "what does the user see during a partition?" each time.

Frequently asked questions

What is the CAP theorem in simple terms?

The CAP theorem says that a system which stores data on more than one machine cannot simultaneously guarantee all three of consistency (every read sees the latest write), availability (every request gets a non-error response) and partition tolerance (the system keeps working when the network between nodes fails). In practice, because networks do fail, partition tolerance is not optional — so when a partition happens you must choose between staying consistent (refuse requests you can't answer correctly) and staying available (answer anyway with possibly-stale data). It is a statement about the trade-off forced on a replicated datastore the moment its nodes can't talk to each other.

Why can't a distributed system have all three of C, A and P?

Because during a network partition, consistency and availability directly conflict. Imagine a node cut off from the rest of the cluster receives a request. To stay consistent it must refuse, since it cannot confirm it has the latest data — but refusing breaks availability. To stay available it must answer from its local copy — but that copy may be stale, which breaks consistency. You cannot do both at once on that node, and since partitions are unavoidable in a multi-machine system (so P is mandatory), you are always forced to sacrifice either C or A when one occurs.

What is the difference between CP and AP systems?

A CP system prioritises consistency: during a partition it stops serving requests it cannot guarantee are correct — the unreachable side returns errors or blocks — so data never diverges, at the cost of some requests failing. HBase, ZooKeeper, etcd and Spanner lean CP. An AP system prioritises availability: during a partition every reachable node keeps answering from its own replica, so no request fails, but different nodes may briefly return different values that reconcile afterwards (eventual consistency). Cassandra, DynamoDB and Riak lean AP. Many of these are tunable per request through quorum settings, so the label is a default rather than a hard rule.

Is a CA system possible?

Not in a genuinely distributed setting. "CA" means a system that is consistent and available but gives up partition tolerance — which only holds if partitions can never happen, and the only way that is true is a single node with no network between replicas to split. A traditional single-server relational database is sometimes called CA, but the instant you replicate it across machines, the network can partition them and you are back to choosing CP or AP. That is why experienced engineers treat CAP as a binary CP-versus-AP choice rather than a menu of three.

What is PACELC and how does it extend CAP?

PACELC fills the gap CAP leaves: CAP only tells you what happens during a partition, which is rare, and says nothing about normal operation. PACELC reads "if Partition, choose Availability or Consistency; Else, choose Latency or Consistency." The "else" branch captures the everyday trade-off — replicating synchronously for strong consistency adds latency, while replicating asynchronously for low latency weakens consistency, even when nothing is broken. So a system is described with both halves: DynamoDB is PA/EL (available when partitioned, low-latency otherwise), while a strict store like Spanner is PC/EC. It is the more complete model to reach for after you've named CAP.

How do I practise using the CAP theorem out loud?

Reading the theorem is not the same as making the call while someone presses on the consequence. On Zynter, the high-level design track runs live voice rounds modelled on how real system design loops run — you talk through a design on the canvas, and a voice interviewer pushes with the follow-ups above one at a time ("the link drops — do you accept the write or reject it? what does the user see?"), then gives you a debrief on problem solving, communication, technical execution and time management. The score is a practice signal, not a hiring decision.

Practise it on Zynter

You can recite CAP. The round is won by making the CP-or-AP call out loud and owning what the user sees.

Pick a high-level design round, reach for the CAP decision when you choose a datastore, and defend it to a voice interviewer that keeps asking "the network splits — do you answer or refuse?" and "what does the user see during the partition?" — then read the debrief. Zynter.ai is on-demand mock interviews modelled on real company loops, with 150+ rounds across 20 companies including the HLD system design track (Sep 2026).

Practise an HLD round →
Browse all interview tracks

Consistent hashing explained: the trick that keeps a cluster calm when a node joins or dies

Gowtham Potureddi — Mon, 19 Oct 2026 04:31:13 +0000

Consistent hashing explained: the trick that keeps a cluster calm when a node joins or dies

Consistent hashing is one of those system design interview ideas that sounds like trivia until the follow-up lands: you have a fleet of cache servers or a sharded database, you add one machine, and suddenly the whole thing falls over. The reason is the naive way of spreading keys across servers — hash(key) % N — and the reason consistent hashing exists is to stop exactly that collapse. If you have ever drawn "shard this across N nodes" on a whiteboard, you have already walked up to the edge of this concept; the question is whether you can explain what happens at the edge.

The one-sentence version, the one worth being able to say out loud in any distributed systems round: with plain modulo hashing, changing the number of servers remaps almost every key at once, but consistent hashing places servers and keys on a ring so that adding or removing a node only moves about K/N of the keys — and virtual nodes keep that movement spread evenly across the cluster. This explainer builds that sentence up from nothing: first why modulo hashing breaks, then the ring that fixes it, then the virtual nodes that make the ring usable in production — and finally where it shows up in the real rounds, and how to narrate it when someone is pushing back.

Why consistent hashing comes up in system design interviews

Consistent hashing is rarely the question on its own — it is the follow-up hiding inside a bigger one. The moment your design says "spread the data across N nodes" or "route each key to one of N cache servers" — a distributed cache, a sharded key-value store, a CDN choosing an edge, a message queue partitioning by key — the interviewer has a lever to pull: what happens to that mapping when N changes? Nodes are not static. They die, you add capacity for a traffic spike, you take one down to patch it. If your routing scheme reshuffles everything each time, your cache goes cold and your storage layer melts under a mass data migration.

"You have a 10-server cache fleet and you add one more to handle load. With a simple hash-and-modulo scheme, what fraction of your keys now map to a different server — and why should that terrify you?" The answer is roughly 10 out of 11 keys move, almost all of them, so almost every request becomes a cache miss at the same instant and stampedes your origin. That is the failure consistent hashing is designed to prevent, and naming it is the point of the question.

These rounds are modelled on how the loop runs — the way a real interviewer probes a design — not scraped from anyone's recall. What matters for prep is the pattern: the concept is easy to define and hard to defend, and the defence is where the points are.

What the interviewer is really testing

Naming "consistent hashing" earns you nothing; explaining it earns you the round. The probe reads on three of the four debrief dimensions. Problem solving: do you reach for it at the right moment — the instant data or traffic must spread across a changing set of nodes — and can you say why modulo fails rather than just that it does? Communication: can you compress it to one sentence — a membership change moves ~K/N keys, not all of them, and virtual nodes keep it balanced — instead of hand-waving at "a ring"? Technical execution: do you actually know the mechanics — how keys and servers map onto the ring, who owns a key, how many keys move, and what virtual nodes buy you? Reading the definition gets you recognition; only saying it out loud under follow-ups gets you fluency.

The problem: why modulo hashing breaks

Start where every candidate starts, because the interviewer wants to hear you reject it for the right reason. To spread K keys across N servers, the obvious scheme is:

server_index = hash(key) % N

While N is fixed, this is great — a good hash function spreads keys evenly, each server gets roughly K/N of them, and lookup is a single modulo. The whole scheme rests on one brittle assumption: N never changes. The day it does, the % N term changes for every key at once, and almost every key is now assigned to a different server.

A small, concrete illustration — the kind you would sketch on the board. Take keys whose hashes are the numbers 10 through 17, and start with N = 4 servers:

Key hash	`% 4` → server	`% 5` → server (after adding one)	Moved?
10	2	0	moved
11	3	1	moved
12	0	2	moved
13	1	3	moved
14	2	4	moved
15	3	0	moved
16	0	1	moved
17	1	2	moved

Adding a single server moved all eight keys. That is not a quirk of this example — with modulo hashing, a change of one in N remaps on the order of all the keys, because the divisor itself changed. Now picture the two places this scheme actually lives. In a distributed cache, every moved key is suddenly a miss, so the instant you add or lose a node, almost the entire fleet misses at once and every request falls through to the origin database — a cache stampede that can take the origin down. In a sharded store, "the key moved" means the data has to physically move to its new shard, so a one-node change triggers a migration of almost the whole dataset. Either way, the thing you reach for next has to satisfy one property: when the node set changes, as few keys as possible should move.

The fix: the hash ring

Consistent hashing changes one thing — it stops tying a key's owner to the count of servers. Instead of mapping keys into N buckets, map both keys and servers into the same large, fixed circular keyspace — think of the output range of the hash function, 0 to 2^32 − 1, bent into a ring so the largest value wraps back to zero.

Place the servers. Hash each server (by its name or IP) to a point on the ring. The number of servers no longer appears in the key's formula at all — servers are just points on a fixed circle.
Place the keys. Hash each key to a point on the same ring.
Assign ownership. A key is owned by the first server you meet going clockwise from the key's point. That server, and only that server, is responsible for it.

The payoff is entirely in what happens on a membership change. Add a server: it lands at one point on the ring and takes over only the keys in the arc between it and the previous server clockwise — the keys that used to belong to its clockwise neighbour. Every other key on the ring is untouched. Remove a server (it crashed): only the keys it owned move, and they all go to the next server clockwise. Nothing else moves.

So instead of remapping almost everything, a one-node change moves, on average, the keys in a single arc — roughly K/N keys (K keys spread over N servers). That is the whole idea, and it is the sentence to say out loud: keys and servers live on the same ring, a key belongs to the next server clockwise, so adding or removing a node only disturbs one arc — about K/N keys — while the rest of the cluster never notices.

Virtual nodes: keeping the ring balanced

The plain ring has a weakness, and a good interviewer will find it, so raise it yourself. With only a handful of servers hashed onto the ring, the points land wherever the hash function throws them — and random points on a circle are lumpy, not evenly spaced. Two problems follow. First, unbalanced load: if one server happens to sit just after a long empty arc, it owns a disproportionate share of the keyspace and runs hot while others idle. Second, a big blast radius on failure: when a server dies, its entire arc dumps onto the single next server clockwise — so one node's death can double the load on one unlucky neighbour, which may then fall over in turn.

The fix is virtual nodes (also called vnodes or tokens). Instead of hashing each physical server to one point, hash it to many points — dozens or hundreds — scattered around the ring, each a "virtual" copy of that server. Two things improve at once:

Even distribution. With many small arcs per server interleaved all around the ring, the law of large numbers smooths the load — the more virtual points per server, the tighter each server's share converges on its fair K/N, and the hot-spot risk shrinks.
A small, spread-out blast radius. When a physical server dies, each of its virtual points hands its little arc to a different clockwise neighbour, so the departing load is spread across all the surviving servers instead of crushing one.

Virtual nodes also give you a clean way to handle heterogeneous hardware: a server with twice the capacity simply gets twice as many virtual points, so it owns twice the keyspace — weighting falls out of the same mechanism. This is why real systems never ship the naive one-point-per-node ring; vnodes are what make consistent hashing usable in production.

"Your ring is live and one node is taking nearly double the traffic of the others. What went wrong, and how do you fix it without re-sharding the world?" The cause is a lumpy ring — too few points per server, so that node owns an oversized arc. The fix is virtual nodes: give every physical server many points on the ring so the arcs even out and load converges on its fair share, and a future node failure spreads across all survivors instead of one. No mass remap required — that is the point of the ring.

System Design
HLD · Core concept
Explain the ring and virtual nodes out loud, under follow-ups

Practise on Zynter →

Where consistent hashing shows up in real systems

The reason this concept is worth owning is that it is load-bearing in half the HLD rounds you will draw. When you reach it in a design, name the system it belongs to — that is what turns "I know the ring" into "I know where the ring goes."

Dynamo and Cassandra partitioning. Both spread data across the cluster with a token ring — consistent hashing with many tokens (virtual nodes) per server. A node joining or leaving the cluster only reshuffles its neighbours' ranges, which is what lets these stores scale and heal without a global migration.
Distributed caches. A memcached or Redis cache fleet sharded client-side uses a ring so that losing a cache node only cools one arc of keys, not the whole cache — exactly the stampede the modulo scheme caused.
CDNs. Edge-server and origin-shield selection can use consistent hashing so that a given object consistently lands on the same edge cache, keeping hit rates high as the edge fleet changes.
Load balancers and sharded-database routing. Any routing layer that must send "the same key to the same node" while the node set changes under it reaches for the ring — session or shard affinity being the common case.

The common thread, and the line that ties it together: consistent hashing is the answer whenever you need to route a key to a node such that changing the node set moves as few keys as possible.

System Design
HLD · Core concept
Drop the ring into a Distributed Cache or Key-Value Store round

Practise on Zynter →

How to talk about consistent hashing in an interview

Scan the probes above and they rhyme. Master these five and you can defend the concept in any round that leans on it, not just recite the definition.

"Why not just use hash(key) % N?" → Because the moment N changes, the divisor changes for every key, so almost all keys remap at once — a cold cache that stampedes the origin, or a near-total data migration in a sharded store. The requirement is that a membership change move as few keys as possible. (problem solving)
"How does the ring actually assign a key to a server?" → Hash both servers and keys onto a fixed circular keyspace; a key is owned by the first server clockwise from it. Adding or removing a node only reassigns the one arc next to it — about K/N keys — leaving the rest untouched. (technical execution)
"Add one node to a fleet of N — how many keys move?" → Roughly K/N on average: just the keys in the new node's arc, taken from its clockwise neighbour. Compare that with modulo hashing, where nearly all K keys move. (communication)
"Your load is uneven / one node runs hot — why, and what's the fix?" → A lumpy ring from too few points per server. Add virtual nodes: many points per physical server so arcs even out and a failure spreads across all survivors. Weight bigger machines with more vnodes. (technical execution)
"Where would you actually use this?" → Dynamo/Cassandra token rings, distributed caches, CDN edge selection, sharded-DB and load-balancer routing — anywhere a key must map to a node while the node set changes. (problem solving)

Each maps to a debrief dimension. Reading the list teaches you the answers; it does not teach you to deliver them while someone interrupts — that only comes from saying them out loud.

How to prepare: a short plan

You do not need a week for this one — you need it automatic, so it drops cleanly into the middle of a bigger design without breaking your stride.

Draw the ring from memory. Circle, a few servers as points, a few keys, each key's clockwise arrow to its owner. If you can draw it in thirty seconds, you can draw it while talking.
Derive K/N yourself. Add a node on your drawing and shade exactly which keys move. Say the number out loud: "about K over N, one arc."
Explain virtual nodes in one sentence. "Many points per server so load is even and a failure spreads across everyone." Then the weighting corollary for mixed hardware.
Then defend it under pressure. Answer the five follow-ups above out loud, with someone (or something) pushing back — that is the rep that turns recognition into fluency.

This explainer is the concept behind one row of the broader Top 25 system design interview questions — once the ring is automatic, it slots into the Distributed Cache, Key-Value Store, CDN and Message Queue walkthroughs without a second thought.

Frequently asked questions

What is consistent hashing, in one sentence?

Consistent hashing is a way to map keys to servers so that adding or removing a server moves only a small fraction of the keys instead of almost all of them. It works by hashing both servers and keys onto the same fixed circular keyspace (a ring) and assigning each key to the first server clockwise from it. Because a key's owner depends on its position on the ring rather than on the total number of servers, a membership change only reassigns the keys in one arc — on average about K/N of them, where K is the number of keys and N the number of servers.

Why not just use `hash(key) % N`?

Because % N ties every key's assignment to the server count N. A good hash spreads keys evenly while N is fixed, but the instant N changes — you add capacity or a node dies — the modulo result changes for essentially every key, so almost all of them map to a different server at once. For a cache that means a near-total set of simultaneous misses stampeding the origin database; for a sharded store it means migrating nearly all the data. Consistent hashing exists specifically to avoid that mass remap.

What are virtual nodes and why do they matter?

Virtual nodes (also called vnodes or tokens) mean hashing each physical server to many points on the ring instead of one. They fix the two weaknesses of a plain ring. First, with only a few points the ring is lumpy, so some servers own oversized arcs and run hot; many points per server smooth the load toward each server's fair share. Second, without vnodes a dying server dumps its whole arc on one neighbour, but with many points its load spreads across all the surviving servers. Virtual nodes also let you weight heterogeneous hardware — a bigger machine simply gets more points.

Where is consistent hashing actually used?

In data stores that partition across a cluster, such as Amazon Dynamo and Apache Cassandra, which use a token ring (consistent hashing with many tokens per node) to distribute data and to rebalance when nodes join or leave. In distributed caches like memcached or Redis sharded across many servers, so losing one node only cools one arc of keys. In CDNs for edge-server and origin-shield selection, to keep an object on the same cache as the fleet changes. And in load balancers and sharded-database routing layers that must send the same key to the same node while the node set shifts.

Is consistent hashing the same as sharding?

No — they are related but not the same. Sharding is the broad idea of splitting data across multiple nodes so no single node holds everything. Consistent hashing is one strategy for deciding which shard a key belongs to — specifically, a hash-based strategy chosen because it keeps key movement small when the number of shards changes. You can shard by range or by a lookup table instead; you reach for consistent hashing when you want even distribution and minimal reshuffling as nodes come and go.

How do I practise explaining consistent hashing out loud?

Reading this page is not the same as defending the ring while someone interrupts with "add a node — how many keys move?" On Zynter, the HLD track runs live voice rounds modelled on how real system design loops run — you draw on a shared canvas and a voice interviewer pushes with follow-ups one at a time, including the partitioning and rebalancing questions this concept lives inside, then gives you a debrief on problem solving, communication, technical execution, and time management. The score is a practice signal, not a hiring decision.

Practise it on Zynter

You can read what a hash ring is. The round is won on explaining K/N out loud while someone pushes back.

Pick an HLD round that leans on partitioning — the Distributed Cache, Key-Value Store or CDN — draw the ring on the canvas, and defend it out loud to a voice interviewer that keeps asking "add a node — what moves?" and "one node is hot — why?" — then read the debrief. Zynter.ai is on-demand mock interviews modelled on real company loops, with 150+ rounds across 20 companies including the HLD system design track (Sep 2026).

Practise an HLD round →
Browse all interview tracks

Design Yelp: the proximity-search system design walkthrough

Gowtham Potureddi — Mon, 19 Oct 2026 04:20:30 +0000

Design Yelp: the proximity-search system design walkthrough

The request to design Yelp sounds like a database with a map on top — a table of businesses, a search box, a list of results — and that picture is exactly what the round is built to puncture. The moment you say "show me the restaurants near me," you have asked a question a normal table cannot answer: find every business within one kilometre of this point, out of fifty million rows, in a few milliseconds. This is one of the most revealing proximity search system design prompts because it is not really about storing businesses or serving reviews — it is about geospatial search: turning "near me" into something an index can look up without scanning the world.

The round turns on one structural insight. "Find places near me" is a geospatial range query, not CRUD over a businesses table — and the naive answers both fail in a way the interviewer is waiting for. You cannot scan all fifty million rows and compute a distance for each on every search, and a plain B-tree index on latitude and longitude does not save you either: it narrows one dimension but still leaves a long thin strip of the map to scan. The job is to map two-dimensional proximity onto a one-dimensional, indexable key so that "nearby" becomes "shares a prefix" or "lives in the same cell." That has three well-known answers — a geohash (encode the coordinates into a prefix string), a quadtree (recursively subdivide the map until each cell is small), and Google S2 (number cells along a space-filling curve) — and naming them, picking one, and defending the choice under uneven density is the spine of the round. Get that reframe — a range query answered by a cell index, then refined with exact distance — and the rest of the system design interview is deciding how a radius becomes a set of cells, how you avoid missing a result sitting just over a boundary, and how the whole thing stays fast when it is read a hundred times for every write. This walkthrough follows the path a strong candidate draws on the whiteboard — requirements, estimate, API and data model, high-level design, then the deep dives — naming the follow-up the interviewer uses at each step to tell a memorised answer from real understanding.

How the proximity-search round is actually run

A proximity-search round runs about 45 minutes on a shared canvas — you draw the boxes and arrows while you talk, and the interviewer interrupts. It is graded as a Medium system design problem, and that matters for how you spend your time: the win here is not surviving some exotic scale, it is reaching a clean geospatial index quickly and defending the one trade-off that actually bites — what happens when density is wildly uneven. A candidate who nails the index, the query flow and the density story, and leaves the review-and-photos features for later, is doing exactly what the round rewards.

The interviewer rarely lets "search the businesses table" stand. "A user is standing downtown and wants every restaurant within one kilometre, ranked by distance — there are fifty million businesses in your system. Walk me through what your service actually does, and don't tell me it scans the table." That question — turning a radius into a bounded lookup — is the one a copied answer can never rehearse, and the one this round is really testing.

The rounds here are modelled on how the loop runs, not scraped from any candidate's recall. What matters for prep is the shape: a blank canvas, a Medium-weight problem with one sharp trade-off, and a follow-up after every decision you make.

The five-step framework for any HLD round

Every high-level design answer fits the same spine. Say it out loud at the start so the interviewer knows you have a plan, then walk it:

Clarify requirements — functional and non-functional, and what you are explicitly not building.
Estimate — number of businesses and search queries per second versus write rate, to justify every later choice.
High-level design — the boxes and arrows: the clients, the search service, the geospatial index, and the business-metadata store.
Deep dive — the two or three decisions that actually decide this system.
Follow-ups — bottlenecks, failure modes, and what you would change at ten times the scale.

What the debrief measures

The score is not "right or wrong design." A good HLD debrief reads on four dimensions, and every move below maps to one: problem solving (did you reframe it as a geospatial range query and reach a cell index, naming geohash, quadtree and S2), communication (did you say in one sentence how each index maps 2D proximity to a 1D key and when you'd pick each), technical execution (covering cells plus their neighbours, an exact haversine filter, ranking and pagination, with the geo index kept separate from the metadata), and time management (did you spend your 45 minutes on the index, the query flow and density, not on the review system). Reading a walkthrough teaches the design; it does not teach you to deliver it on the clock while someone pushes back.

Step 1 — Requirements: what a proximity search service must do

Spend the first few minutes here. Jumping to boxes before you have scoped the problem is the fastest way to design the wrong system.

Type	Requirement
Functional	A user searches for businesses within a radius of a location (or a map viewport) and gets them back ranked; each result shows name, category, rating and distance; a user can open a business and read its details; businesses can be added and their details updated.
Functional (optional)	Filter by category or "open now", sort by rating versus distance, full review read/write, photos, autocomplete on business names — call these out, then scope most of them for later.
Non-functional	Low-latency reads — a search returns in milliseconds; the system is heavily read-dominated and business data changes slowly, so eventual consistency on a business edit is fine; high availability; scale to tens of millions of businesses and a high search query rate.

The sentence that earns points: "This is a geospatial range query, not CRUD — I can't scan fifty million rows per search and a plain latitude/longitude index doesn't help, so the core of the design is a spatial index that maps 2D proximity to a 1D key I can look up." Say that and you have framed the entire design before drawing a box.

Step 2 — Capacity estimation (back of the envelope)

Estimation here is about proving one thing: the load is overwhelmingly reads against mostly static data, and the only hard part is the spatial lookup — everything else is a cacheable, replicable read store.

Quantity	Assumption	Result
Total businesses	tens of millions worldwide	a large but bounded dataset — small enough to index in memory per region, too large to scan per query
Search queries	very high rate, every map pan and "near me" tap	read-heavy; the spatial lookup must be an indexed cell read, never a scan
Writes (new / edited business)	rare, and tolerant of a short delay	the index and metadata can be updated lazily; no write-path pressure
Density per area	wildly uneven — a downtown cell may hold thousands, a rural cell a handful	the index must cope with non-uniform density, the trade-off that decides geohash vs quadtree

Two conclusions fall out, and you should say both out loud. First, the system is read-heavy and slow-changing, so after the index is right, scaling is the easy part: cache popular searches, serve metadata from read replicas, and never let a write path become the bottleneck. Second, there are two layers that should be kept apart — the spatial layer that answers which businesses are near this point (the geo index, the hard problem) and the metadata layer that answers what are they (name, hours, rating, reviews — a normal, cacheable store). You have now pointed the interview at the real deep dives — the index, the query flow, and density — before anyone asked.

Step 3 — API and data model

The API is deliberately small: a client searches around a point, opens a business, and occasionally a business is written.

Operation	Shape
`search_nearby(lat, lng, radius, filters, page)`	the core read — returns businesses within the radius, ranked, paginated.
`get_business(business_id)`	one-off read of a single business and its details.
`add_or_update_business(business)`	writes name, location, category and attributes; updates both the index and the metadata store.
`search_by_viewport(bounding_box, filters)`	map-pan variant — returns businesses inside a rectangle instead of a radius.

The data model splits along the two layers. The geo index is keyed by spatial cell; the business metadata is a plain record read far more often than it is written:

Entity	Notes
`business`	`business_id`, `name`, `lat`, `lng`, `category`, `rating`, `cell_key` — the metadata record, stored in a normal, replicated store.
`geo_index`	`cell_key → [business_id, …]` — the spatial index that turns a cell into the businesses inside it (geohash prefix, quadtree node, or S2 cell id).
`review`	`(business_id, user, stars, text)` — part of the metadata layer; scope the full review system for later in this round.

Step 4 — High-level design: the search service, geo index and metadata store

Now the boxes. A client sends a location and radius; a search service turns that into a cell lookup, fetches candidates, refines and ranks them, and reads the details from a separate store:

API gateway: terminates the client request and routes search_nearby to the search service.
Search service: the heart of the system. It computes the covering cells for the radius, reads the candidate business ids from the geo index, computes exact distance to drop false positives, ranks the survivors, and paginates.
Geospatial index: maps a cell key to the business ids inside it — a geohash prefix, a quadtree node, or an S2 cell id. This is the structure that makes "near me" an indexed read instead of a scan.
Business metadata store: the businesses themselves (name, hours, category, rating, reviews), fronted by read replicas because it is read far more than written.
Cache: popular searches and hot cell → businesses results sit in a cache, since the same busy areas are searched over and over.
Write path: adding or editing a business is rare and slow-changing — it updates the metadata store and the geo index, and the caches expire naturally.

Say explicitly that the design has two layers kept apart: the spatial layer answers which businesses are near, and the metadata layer answers what they are. Naming that split — a search service over a cell index, backed by a separately scaled read store — is a signal the interviewer is listening for.

Deep dive: the geospatial index (geohash vs quadtree vs S2)

This is the decision the whole round is really about. The follow-up is the one from the top: find every restaurant within one kilometre of me — how, without scanning all fifty million businesses?

Start by killing the naive answers out loud. A full scan computes a distance for every business on every search — impossible at this scale. A plain B-tree on latitude and longitude looks tempting but barely helps: an index on lat narrows you to a horizontal band of the whole planet, an index on lng to a vertical one, and you are still left scanning a huge strip — two 1D indexes do not compose into a 2D range. The fix is to map 2D proximity to a single indexable key, so that points near each other on the map are near each other in the index. There are three standard ways, and a strong answer names all three before picking one:

	Geohash	Quadtree	Google S2
Idea	interleave the bits of lat and lng and base-32 encode them into a prefix string; nearby points share a prefix	recursively split each square into four quadrants until a cell holds at most N points	number cells along a Hilbert curve so each cell is a 64-bit id and nearby cells have nearby ids
Density	fixed grid — every cell is the same size regardless of how many points fall in it	adapts — dense areas subdivide deeply, sparse areas stay coarse	fine-grained levels; handles the whole globe and the poles cleanly
Where it lives	any string-prefix index — a plain DB column or Redis	an in-memory tree that must be built and rebalanced	a purpose-built library/service
Best fit	simple, portable, "good enough" nearby search	uneven density, where a fixed grid breaks down	planet-scale, Google/Tinder-class systems

For a Yelp-style service, start with a geohash: it needs no special infrastructure — a geohash prefix is just a string column with a B-tree index, and a radius query becomes "the handful of geohash cells that cover the circle." Then say the one sentence that shows range: all three turn 2D proximity into a 1D indexable key — geohash with a fixed grid of prefixes, a quadtree with an adaptive tree, S2 with a Hilbert-curve id — so I'd stay on geohash for simplicity and reach for a quadtree once density is uneven enough that a fixed cell size over-returns downtown and under-fills the countryside. That is the trade-off the round is testing, and it sets up the density deep dive.

"Find every restaurant within one kilometre of me — how, without scanning all fifty million businesses?" I don't scan, and I don't rely on a plain lat/long index — two 1D indexes still leave a strip to scan. I give every business a spatial cell key: a geohash prefix, where nearby points share the prefix. A radius query becomes the small set of geohash cells that cover the circle, so I read only the businesses in those cells — a few hundred candidates, not fifty million — and then refine with exact distance. If density were very uneven I'd use a quadtree so cells adapt to how many businesses are in each area.

System Design
HLD · Search & discovery · 45 min
Design Yelp proximity search out loud, with follow-ups

Practise on Zynter →

Deep dive: the search query flow

The index decides how points are stored; this decides what actually happens on a single search and why the cells are only half the answer. The follow-up is about the edges: a result sits just over a cell boundary from me — how do you not miss it, and how do you keep the results exact?

The flow is a coarse filter then a fine filter: cells get you a small candidate set cheaply, and exact distance makes it correct.

Compute the covering cells: from the user's location and radius, work out the set of cells (geohash prefixes, quadtree nodes or S2 cells) that overlap the search circle. Pick a cell precision whose size is close to the radius so the set stays small.
Include the neighbours: a business just over a cell boundary is still within the radius, so always query the covering cells plus their adjacent cells. This is the classic boundary bug — skip the neighbours and you silently drop nearby results.
Fetch the candidates: read the business ids in those cells from the geo index. This is a bounded set — a few hundred or thousand — not the whole table.
Refine with exact distance: the cells are rectangles, the search is a circle, so compute the exact haversine distance from the user to each candidate and drop any that fall outside the true radius. The index is approximate on purpose; haversine makes the answer precise.
Rank and paginate: sort the survivors by a blend of distance, rating and relevance, then return a page at a time so the client never pulls thousands of rows.

The point to state plainly: the geo index is a coarse filter that trades precision for speed, and the exact-distance step is what makes the result correct — and you must always query the neighbouring cells, because the one place a naive version breaks is a result sitting a few metres over a boundary. Instant "near me" is a cheap cell read followed by a precise distance check, never a scan.

"A result sits just over a cell boundary from me — how do you not miss it, and how do you keep the results exact?" I never query just the single cell the user is in. I compute all the cells that cover the radius and include their immediate neighbours, so a business a few metres over a boundary is still a candidate. Then I compute the exact haversine distance for every candidate and drop the ones outside the true radius — the cells are a coarse filter, the distance check is the precise one. That way nothing near the edge is lost and nothing outside the circle sneaks in.

System Design
HLD · Search & discovery · 45 min
Defend the covering-cells + haversine flow out loud

Practise on Zynter →

Deep dive: density, scale and read-heaviness

Getting the index and the query flow right keeps a single search correct; this decides whether the design holds up across a real map and a real load. The follow-up is the one that separates a memorised answer from an understood one: one downtown cell has ten thousand places and a rural cell has two — how does your index handle both, and how do you serve a hundred times more reads than writes?

Two forces shape this answer — uneven density and a read-heavy, slow-changing workload:

Density is the real trade-off: a fixed-grid geohash uses one cell size everywhere, so the dense downtown cell returns ten thousand candidates you must then distance-filter, while a rural cell of the same size holds almost nothing. A quadtree adapts: it subdivides the dense region into many small cells and leaves the empty region as one large cell, so every cell holds a roughly bounded number of businesses. Saying that out loud — fixed grid is simpler but struggles with uneven density; the quadtree subdivides only where it is dense — is the single most important sentence in this round.
Tune geohash precision as a cheaper fix: if you want to stay on geohash, use a longer prefix (smaller cell) in dense areas and a shorter one in sparse areas, which approximates what the quadtree does for free.
The load is overwhelmingly reads: people search far more than businesses change, so cache popular searches and hot cell → businesses results; the same busy areas are queried constantly and the data behind them barely moves.
Scale reads with replicas: serve the business-metadata reads from read replicas, and keep them separate from the spatial lookup so a hot metadata read does not contend with the index.
Writes are easy: a new or edited business is rare and tolerant of a short delay, so the write path updates the index and metadata lazily and lets caches expire — there is no write bottleneck to engineer around.

The point to state plainly: the hard part of scaling this system is not throughput, it is density — the index must not blow up in a dense cell or waste space in an empty one — and once the index handles density, the read-heavy load is absorbed almost entirely by caching and read replicas over slow-changing data. Keep the geo index and the metadata store separate so each scales on its own terms.

The follow-ups that decide the proximity-search round

Scan the probes from each deep dive and they rhyme. Master these five and you are ready for a version of the question that is not drawn exactly like this one.

"Why not just index latitude and longitude and query a range?" → Because two separate 1D indexes don't compose into a 2D range — each narrows one axis to a planet-long strip you'd still scan. You need a single spatial key (geohash, quadtree or S2) so points near on the map are near in the index. (problem solving)
"Geohash, quadtree or S2 — which and why?" → Geohash for a simple, portable index that's just a string column; a quadtree when density is uneven, because it subdivides dense areas and leaves sparse ones coarse; S2 for planet-scale with a Hilbert-curve cell id. All three map 2D proximity to a 1D indexable key. (communication)
"A result sits just over a cell boundary — how do you not miss it?" → Query the covering cells plus their neighbours, then compute exact haversine distance and drop anything outside the true radius; the cells are a coarse filter and the distance check is the precise one. (technical execution)
"One cell has ten thousand businesses and another has two — how does your index cope?" → A fixed-grid geohash over-returns in the dense cell and wastes the sparse one; a quadtree adapts by subdividing only where it is dense, or you tune geohash precision per area to approximate it. (technical execution)
"This is a hundred times more reads than writes — how do you scale?" → Cache popular searches and hot cell-to-businesses results, serve metadata from read replicas, and keep the geo index separate from the metadata so each scales independently; writes are rare and can be lazy. (problem solving)

Each maps to a debrief dimension. Reading this list teaches you the answers; it does not teach you to deliver them while someone interrupts — that only comes from saying them out loud.

How to prepare: a one-week plan

You do not need fifty systems. You need this one cold and the framework automatic, so the next "design X" is just new nouns in the same five steps.

Days 1–2: Learn the five-step framework until it is reflex. Do the proximity service end to end on paper — requirements, estimate, API, data model, and the search-service / geo-index / metadata boxes.
Days 3–4: Drill the geospatial index: why a scan and a plain lat/long index both fail, how a geohash prefix encodes a cell, how a quadtree subdivides, and what S2 adds — and say in one sentence when you'd pick each.
Days 5–6: Own the query flow and density — covering cells plus neighbours, the exact haversine refine, ranking and pagination, and the fixed-grid-vs-quadtree density trade-off plus caching and read replicas. Answer each of the five follow-ups out loud.
Day 7: A full timed 45-minute round, narrating the whole way, with someone (or something) interrupting. This is the rep that counts.

This post is the deep walkthrough behind one row of the broader Top 25 system design interview questions — once the proximity service is automatic, the same spine carries the rest of the list.

Frequently asked questions

How do I design Yelp step by step?

Follow the five-step HLD framework. Clarify requirements (search businesses within a radius of a location and get them ranked with name, category, rating and distance; open a business for details; add and edit businesses; the system is read-heavy and business data changes slowly); estimate to show that the load is overwhelmingly reads against tens of millions of mostly static businesses with wildly uneven density; define the small API (search_nearby, get_business, add_or_update_business, a viewport variant) over two layers — a spatial index and a business-metadata store; draw the design (clients → API → search service that computes covering cells, reads candidates from a geospatial index, refines by exact distance, ranks and paginates, backed by read replicas and a cache); then deep-dive the geospatial index (geohash vs quadtree vs S2), the query flow (covering cells plus neighbours then haversine), and density plus read-scaling. Finish on the follow-ups about boundaries, density and read-heaviness.

How do you find nearby places without scanning every business?

By giving every business a spatial cell key so "near me" becomes an indexed cell lookup instead of a scan. A full scan computes a distance for every row on every search, which is impossible at tens of millions of businesses, and a plain B-tree on latitude and longitude barely helps because two separate 1D indexes do not compose into a 2D range — each leaves a planet-long strip to scan. Instead you encode each location into a geohash prefix (or a quadtree node, or an S2 cell id) so nearby points share a key, turn a radius into the small set of cells that cover it, read only the businesses in those cells, and then refine with exact distance. You go from fifty million rows to a few hundred candidates.

What is a geohash?

A geohash is a way of encoding a latitude/longitude pair into a short string so that nearby points share a common prefix. You interleave the bits of the latitude and longitude and base-32 encode the result; the longer the string, the smaller and more precise the cell it names. Because nearness on the map becomes a shared string prefix, a geohash works with any ordinary string index — a plain database column or a key in Redis — and a "find nearby" query becomes "the handful of geohash cells that cover this circle." Its limitation is that it is a fixed grid: every cell at a given precision is the same size regardless of how many businesses fall inside it, which is why uneven density pushes designs toward a quadtree.

Geohash vs quadtree vs S2 — what's the trade-off?

All three turn two-dimensional proximity into a one-dimensional indexable key; they differ in how they handle density and where they live. A geohash is a fixed grid of equal cells encoded as prefix strings — simplest and portable, it runs on a plain index, but a uniform cell size over-returns in dense areas and wastes space in sparse ones. A quadtree recursively splits each square into four until a cell holds at most N points, so it adapts to density — dense regions subdivide deeply, sparse regions stay coarse — at the cost of maintaining an in-memory tree. Google S2 numbers cells along a Hilbert curve so each map cell is a 64-bit id with nearby cells sharing nearby ids, handling the whole globe cleanly for planet-scale systems. Pick geohash for simplicity, a quadtree for uneven density, S2 at global scale.

How do you handle uneven density and a read-heavy load?

Density is the real trade-off. A fixed-grid geohash uses one cell size everywhere, so a downtown cell can hold ten thousand businesses while a rural cell holds two — the dense cell returns far too many candidates and the sparse one too few. A quadtree solves this by subdividing only where it is dense and leaving empty regions coarse, so each cell holds a bounded number of businesses; alternatively you tune geohash precision per area to approximate the same effect. The load itself is overwhelmingly reads against slowly changing data, so you cache popular searches and hot cell-to-businesses results, serve business metadata from read replicas, and keep the geo index separate from the metadata store so each scales on its own and a rare write never becomes a bottleneck.

How do I practise a system design interview out loud?

Reading a walkthrough is not the same as defending a design while someone interrupts. On Zynter, the HLD track runs live voice rounds modelled on how real system design loops run — you talk through a shared design on the canvas, and a voice interviewer pushes with the follow-ups above one at a time, then gives you a debrief on problem solving, communication, technical execution, and time management. The score is a practice signal, not a hiring decision.

Practise it on Zynter

You can read what a geohash is. The round is won on turning a radius into cells out loud.

Pick the Local Business Search (proximity) round, draw the search-service, geo-index and metadata design on the canvas, and defend it out loud to a voice interviewer that keeps asking "find every restaurant within a kilometre without scanning fifty million rows — how?" and "one cell has ten thousand places and another has two — now what?" — then read the debrief. Zynter.ai is on-demand mock interviews modelled on real company loops, with 150+ rounds across 20 companies including the HLD system design track (Sep 2026).

Practise the Proximity Search round →
Browse all interview tracks

Design Dropbox: the file storage and sync system design walkthrough

Gowtham Potureddi — Mon, 19 Oct 2026 04:07:55 +0000

Design Dropbox: the file storage and sync system design walkthrough

The request to design Dropbox sounds like one line — put my files in the cloud and keep them the same on every device — and that one line hides the whole interview. Picture it as upload and download and you reach for a form, a blob store and a save button; picture it as file storage and sync where a 1 GB video has one byte changed, a laptop and a phone must both end up identical, and two machines edited the same file while both were offline, and it becomes one of the more deceptively deep problems in distributed systems. This is one of the most revealing file sync system design prompts because it is not about storing bytes first — it is about sync efficiency and consistency: moving only what changed, converging every device on the same file, and never silently losing an edit.

The round turns on one structural insight. "Store my files and sync them" hides the fact that a file is the wrong unit of work — if you treat it as one opaque blob, a one-byte edit forces a gigabyte back over the wire and every save fights every other save. The reframe that unlocks the whole design is to stop treating a file as one blob and treat it as an ordered list of content-addressed chunks: split each file into fixed-size pieces, identify each piece by the hash of its contents, and now sync is just "which chunk hashes changed." Get that reframe — a file is a list of chunk hashes, so you move chunks not files, store each unique chunk once, and let a small metadata service be the source of truth while the bytes live in a blob store — and the rest of the system design interview is deciding how a device learns something changed, how it pulls only what it is missing, and what happens when two devices disagree. This walkthrough follows the path a strong candidate draws on the whiteboard — requirements, estimate, API and data model, high-level design, then the deep dives — naming the follow-up the interviewer uses at each step to tell a memorised answer from real understanding.

How the file-sync round is actually run

A file storage and sync round runs about 45 minutes on a shared canvas — you draw the boxes and arrows while you talk, and the interviewer interrupts. It is a favourite because the one-line problem opens onto deep water fast: the moment you draw "upload the file, download the file," the question becomes what happens when a huge file barely changes and how do two devices stay identical without clobbering each other, and every answer after that compounds from those two. The clock is a touch tighter than the hour-long rounds, so you have to spend your minutes on chunking, the sync flow and conflicts, not on the sharing-permissions screen.

The interviewer rarely lets "just upload it to storage" stand. "You change one byte in the middle of a 1 GB file, and your phone is asleep in your pocket — what actually gets uploaded, how does your phone find out, and what does it download when it wakes up?" That question — efficient, consistent sync of a large file across devices — is the one a copied answer can never rehearse, and the one this round is really testing.

The rounds here are modelled on how the loop runs, not scraped from any candidate's recall. What matters for prep is the shape: a blank canvas, a tighter clock, and a follow-up after every decision you make.

The five-step framework for any HLD round

Every high-level design answer fits the same spine. Say it out loud at the start so the interviewer knows you have a plan, then walk it:

Clarify requirements — functional and non-functional, and what you are explicitly not building.
Estimate — file sizes, edit rates and device counts versus total bytes stored, to justify every later choice.
High-level design — the boxes and arrows: the clients, the metadata service, the notification service, and the blob store the bytes actually live in.
Deep dive — the two or three decisions that actually decide this system.
Follow-ups — bottlenecks, failure modes, and what you would change at ten times the scale.

What the debrief measures

The score is not "right or wrong design." A good HLD debrief reads on four dimensions, and every move below maps to one: problem solving (did you reframe a file as an ordered list of content-addressed chunks and reach chunking, dedup and delta sync), communication (did you say why a one-byte edit must not re-upload a gigabyte, and why bytes go straight to blob storage while app servers touch only metadata, each in a sentence), technical execution (fixed-size hashed chunks, a metadata service holding the chunk list and version sharded by user, a notification service, presigned direct-to-blob transfer, conflicted copies), and time management (did you spend your 45 minutes on sync efficiency and conflicts, not on previews and thumbnails). Reading a walkthrough teaches the design; it does not teach you to deliver it on the clock while someone pushes back.

Step 1 — Requirements: what a file storage and sync service must do

Spend the first few minutes here. Jumping to boxes before you have scoped the problem is the fastest way to design the wrong system.

Type	Requirement
Functional	Users upload and download files; a file is kept identical across all of a user's devices; edits sync automatically and quickly; files can be shared with other users; version history is kept; the client works offline and reconciles on reconnect.
Functional (optional)	Very large files, selective sync (only some folders on a device), previews/thumbnails, trash and restore — call these out, then scope most of them for later.
Non-functional	Sync efficiency — never re-send data that did not change; durability — a stored file is never lost; consistency — every device converges on the same bytes and no edit is silently dropped; high availability; scale to enormous total bytes and many devices per user.

The sentence that earns points: "This is a sync-efficiency and consistency problem, not upload/download CRUD — if I treat a file as one blob, a one-byte edit costs a gigabyte, so I'll treat each file as an ordered list of content-addressed chunks and sync only the chunks that changed." Say that and you have framed the entire design before drawing a box.

Step 2 — Capacity estimation (back of the envelope)

Estimation here is about proving one thing: the bytes are enormous but mostly unchanged between versions, and the metadata is tiny — so the design must move deltas, not files, and keep the two apart.

Quantity	Assumption	Result
Files and devices per user	many files, a handful of devices	a bounded fan-out per account — the unit of work is one user's files across their devices, not the whole fleet
File size and edit rate	files range from kilobytes to many gigabytes; edits usually touch a small fraction of a large file	most bytes are unchanged on edit — a whole-file re-upload would waste almost all of it, so delta sync is the win
Total bytes stored	petabyte-scale and growing	bytes belong in a blob/object store that scales independently, not in your application database
Metadata rows	one small record per file plus its chunk list	metadata is small and consistent — shard by user id and keep it off the data path

Two conclusions fall out, and you should say both out loud. First, there are two planes: a small, consistent metadata plane (what a file is — its chunk list and version) and a huge, content-addressed data plane (the chunk bytes themselves). Keep them separate — app servers manage metadata, bytes go straight to the blob store. Second, because most of a large file is unchanged between versions, the only thing worth syncing is the delta, which is exactly what content-addressed chunking gives you for free. You have now pointed the interview at the real deep dives — chunking and delta sync, the notification/sync flow, and conflicts — before anyone asked.

Step 3 — API and data model

The API is deliberately small: a client asks what the file is now, uploads only the chunks that are new, and subscribes for changes.

Operation	Shape
`get_file_metadata(file_id)`	returns the file's current version and its ordered list of chunk hashes.
`has_chunks(hash[])`	the dedup check — tells the client which of these chunk hashes the store already has, so it uploads only the rest.
`put_chunk(hash, bytes)`	uploads one chunk's bytes directly to the blob store via a presigned URL.
`commit_file(file_id, chunk_hash[], base_version)`	records a new file version as a new ordered chunk-hash list, against the version the client last saw.
`get_chunk(hash)`	downloads one chunk (served via CDN) to reassemble the file.
`subscribe_changes(user_id)`	opens a long-poll/websocket so the device is told when anything under the account changes.

The data model is thin, and the split between metadata and bytes is the whole point:

Entity	Notes
`file`	`file_id`, `owner`, `name`, `version`, ordered `chunk_hash[]` — the metadata source of truth for what the file is; sharded by user id.
`chunk`	`hash` → the chunk's bytes in the blob store; content-addressed so an identical chunk is stored once and referenced many times (deduplication).
`device`	`(user_id, device_id, last_synced_version)` — what each device has already caught up to, so catch-up is a cheap diff.
`version`	the prior `chunk_hash[]` lists per file — history, so nothing is ever truly overwritten.

Step 4 — High-level design: metadata plane, data plane and notifications

Now the boxes. The design is defined by a line drawn through the middle of it — metadata on one plane, bytes on another:

Metadata service: the source of truth for what each file is — its version and ordered chunk-hash list — sharded by user id. It is small, consistent, and never handles file bytes.
Notification service: holds long-lived connections (long-poll or websocket) and tells a device "something under your account changed" so it knows to sync. It pushes a signal, not the data.
Blob / object store: where the chunk bytes actually live, content-addressed by hash, scaling independently as petabytes. Clients read and write chunks directly here via presigned URLs — the app servers never sit in the byte path.
CDN: downloads of chunks are served through a CDN so bytes come from near the user, not from one region.
Chunk index / dedup: a lookup of hashes the store already has, so has_chunks can tell a client to skip anything already stored.

Say explicitly that app servers never touch file bytes: the client chunks and hashes locally, the metadata service tells it which chunks are new, and the bytes flow straight to the blob store via a presigned URL. Naming that split — a light control plane for metadata and notifications, a heavy data plane that scales with the object store and CDN — is a signal the interviewer is listening for.

Deep dive: chunking, deduplication and delta sync

This is the decision the whole round is really about. The follow-up is the one-byte edit: you change one byte in the middle of a 1 GB file — what actually gets uploaded?

Start by killing the naive answer out loud: re-uploading the whole file is unacceptable. A one-byte change does not mean a gigabyte of new data, so sending a gigabyte wastes bandwidth, battery and time. The fix is to make the file addressable in pieces:

Chunk the file: split it into fixed-size chunks (~4 MB is a reasonable default). Chunking is what makes a partial change a small change.
Hash each chunk: compute a hash of each chunk's contents (e.g. SHA-256). The hash is the chunk's identity — this is content addressing. Two chunks with the same bytes have the same hash, anywhere, for anyone.
The file is a list of hashes: metadata stores the file as an ordered list of chunk hashes plus a version. That list, not the bytes, is what the control plane reasons about.
Deduplicate: because chunks are addressed by content, an identical chunk is stored once in the blob store and referenced by every file and user that contains it — saving both storage and upload bandwidth.
Delta sync: editing a file re-chunks it; only the chunks whose hash changed are uploaded or downloaded. Change one byte in a 1 GB file and you re-chunk, find that one ~4 MB chunk has a new hash, upload that single chunk, and commit a new hash list. One chunk moves, not a gigabyte.

The point to state plainly: content addressing turns sync into set arithmetic. "What do I need to upload?" is just "which of my chunk hashes does the store not already have?", and "what do I need to download?" is "which hashes in the new version am I missing?" The whole efficiency of the system falls out of identifying chunks by their contents.

"You change one byte in the middle of a 1 GB file — what actually gets uploaded?" The client re-chunks the file into fixed-size pieces and hashes each one. Only the single ~4 MB chunk containing that byte gets a new hash; every other chunk's hash is unchanged and already in the store. So the client uploads that one chunk and commits a new version that is just a new ordered list of chunk hashes — one chunk on the wire, not a gigabyte. Identical chunks are stored once and reused, so even that upload is skipped if the store already has it.

System Design
HLD · Storage & files · 45 min
Design Dropbox out loud, with follow-ups

Practise on Zynter →

Deep dive: metadata, change notification and the sync flow

Chunking decides what moves; this decides how a device even learns it should move anything, and how the two planes work together. The follow-up is about discovery: how does a second device even know a file changed?

The answer is a notification service plus a diff against the metadata, with bytes pulled straight from the blob store:

Metadata is the source of truth for state: the metadata service holds each file's current version and chunk-hash list, per user. It knows what the file is; the blob store knows the bytes.
A change notification wakes the device: when a file changes, the metadata is updated and the notification service pushes a lightweight signal — over long-poll or websocket — to the user's other devices: "something under your account changed." It sends the nudge, not the data.
The device pulls the delta: on that signal the device calls get_file_metadata, gets the new ordered chunk-hash list, and diffs it against its local list. The chunks whose hashes it does not already have are exactly what it must fetch.
Download only the missing chunks: it fetches just those chunks from the blob store (via CDN), then reassembles the file in the order the hash list specifies. Unchanged chunks are already on disk and are never re-downloaded.
Upload mirrors it: to push a local edit, the client re-chunks, calls has_chunks to learn which hashes are new, uploads only those directly to the blob store, then commit_file records the new version. Offline edits are buffered and run the same diff on reconnect.

The point to state plainly: the notification carries no content — it only triggers a pull, and the pull is a cheap diff of two hash lists. This keeps the control plane tiny and lets the data plane (blob store + CDN) carry the weight. A device that was asleep for a week catches up with exactly the same diff as one that missed a single edit.

"How does a second device even know a file changed?" It holds a long-poll or websocket connection to a notification service. When a file under the account changes, that service pushes a small 'something changed' signal — never the bytes. The device then pulls the updated metadata, diffs the new ordered chunk-hash list against what it has locally, and downloads only the chunks it is missing from the blob store through the CDN, reassembling the file from the hash list. A week offline or one edit behind, it is the same cheap diff.

System Design
HLD · Storage & files · 45 min
Defend the metadata/data-plane split out loud

Practise on Zynter →

Deep dive: scale, consistency and conflicts

Chunking and the sync flow keep a well-behaved account consistent; this decides what happens at petabyte scale and when two devices genuinely disagree. The follow-up is the collision: two of your devices edit the same file while both are offline — what happens when they reconnect?

The scale answers come from the two-plane split; the consistency answer is to detect divergence and keep both copies:

Bytes never touch the app servers: uploads and downloads go directly to the blob store via presigned URLs, so the control plane stays small and the data plane scales with the object store and CDN. App servers move metadata, not gigabytes.
Shard metadata by user id: a user's files and devices are the natural unit of coordination; different users are independent, so metadata scales horizontally and a hot account is one shard's load.
Detect conflicts by version lineage: every commit is made against a base version. If two devices both edited from version N while offline, on reconnect the server sees two different children of the same version — that is a conflict, not a valid linear update.
Never silently overwrite — make a conflicted copy: rather than letting one device clobber the other, the server keeps both: the file and a (Device B's conflicted copy). Both users' work survives, and the person decides how to merge. Last-write-wins would silently destroy an edit, which is unacceptable.
Versioning and resumable uploads: because every version is just a stored chunk-hash list, history is free and restores are cheap; and because uploads are chunked, a dropped connection resumes at the next un-acked chunk instead of restarting the file.

The point to state plainly: consistency here means convergence without loss. A single writer's change propagates by notify-then-pull; concurrent writers are detected by divergent version lineage and resolved by preserving both, never by picking a winner that deletes work. The chunk model makes all of it — dedup, delta, history, resumable uploads — the same mechanism seen from different angles.

"Two of your devices edit the same file while both are offline — what happens when they reconnect?" Each committed its edit against the same base version, so the server sees two different children of that version — a genuine conflict. It never silently overwrites: it keeps the original and writes the other as a conflicted copy named for the device, so neither person's work is lost, and versioning retains the history. A normal single-writer change, by contrast, is just notify-then-pull-the-delta.

The follow-ups that decide the file-sync round

Scan the probes from each deep dive and they rhyme. Master these five and you are ready for a version of the question that is not drawn exactly like this one.

"Why not just re-upload the file when it changes?" → Because a one-byte edit does not mean a gigabyte of new data. Chunk the file into fixed-size pieces, hash each (content addressing), and upload only the chunk whose hash changed — one ~4 MB chunk, not the whole file. (problem solving)
"How do identical files or chunks avoid being stored twice?" → Chunks are addressed by the hash of their contents, so an identical chunk has the same hash everywhere and is stored once and referenced many times — deduplication across versions, files and users. (technical execution)
"How does another device know a file changed, and what does it fetch?" → A notification service pushes a lightweight 'something changed' signal over long-poll/websocket; the device pulls the new chunk-hash list, diffs it against its local list, and downloads only the missing chunks from the blob store via CDN. (communication)
"Why don't the app servers handle the file bytes?" → To keep the control plane light and the data plane scalable: metadata (small, consistent, sharded by user) goes through app servers, but bytes go directly to the blob store via presigned URLs and are served through a CDN. (technical execution)
"Two devices edit offline — who wins?" → Neither is silently overwritten. Both committed against the same base version, so the server detects divergent lineage and keeps both as a conflicted copy, with versioning preserving history. (problem solving)

Each maps to a debrief dimension. Reading this list teaches you the answers; it does not teach you to deliver them while someone interrupts — that only comes from saying them out loud.

How to prepare: a one-week plan

You do not need fifty systems. You need this one cold and the framework automatic, so the next "design X" is just new nouns in the same five steps.

Days 1–2: Learn the five-step framework until it is reflex. Do the file-sync service end to end on paper — requirements, estimate, API, data model, and the metadata-service/notification-service/blob-store boxes.
Days 3–4: Drill chunking: fixed-size chunks, content-addressed hashes, a file as an ordered hash list, deduplication, and delta sync. Say the one-byte-in-a-gigabyte answer in a single sentence.
Days 5–6: Own the sync flow and conflicts — notify-then-pull, diff the hash lists, download only missing chunks, and the conflicted-copy resolution for offline edits. Answer each of the five follow-ups out loud.
Day 7: A full timed 45-minute round, narrating the whole way, with someone (or something) interrupting. This is the rep that counts.

This post is the deep walkthrough behind one row of the broader Top 25 system design interview questions — once the file-sync service is automatic, the same spine carries the rest of the list.

Frequently asked questions

How do I design Dropbox step by step?

Follow the five-step HLD framework. Clarify requirements (upload/download files, keep them identical across a user's devices, sync edits automatically, share with others, version history, work offline then reconcile — with the hard rules of sync efficiency, durability, and convergence with no silent loss); estimate to show that bytes are huge but mostly unchanged on edit while metadata is tiny, which forces delta sync and a two-plane split; define the small API (get_file_metadata, has_chunks, put_chunk, commit_file against a base version, get_chunk, subscribe_changes) over a file/chunk/device/version model; draw the design (clients to a metadata service sharded by user id and a notification service, with chunk bytes flowing directly to a blob store via presigned URLs and served through a CDN); then deep-dive chunking + dedup + delta sync, the notification/sync flow, and scale + conflicts. Finish on the follow-ups about one-byte edits and offline collisions.

How does file sync avoid re-uploading the whole file when it barely changes?

By splitting each file into fixed-size chunks (around 4 MB) and identifying each chunk by a hash of its contents. The file is stored in metadata as an ordered list of those chunk hashes. When you edit the file, the client re-chunks it and compares hashes: only the chunks whose hash changed are new, so only those are uploaded. A one-byte change in a 1 GB file produces exactly one new chunk hash, so roughly one 4 MB chunk moves instead of a gigabyte. This is called delta sync, and it falls directly out of addressing chunks by their content.

What is content-addressable chunking and deduplication?

Content-addressable means a chunk's identity is the hash of its bytes, not a name or location. Two chunks with identical contents produce an identical hash anywhere in the system, for any user. Deduplication uses that property: an identical chunk is stored once in the blob store and simply referenced by every file, version or user that contains it, instead of being stored again. So the same attachment synced by a hundred people, or the unchanged 99% of an edited file, costs storage and bandwidth only once. The file itself is just an ordered list of these content hashes.

How does another device know a file changed, and what does it download?

Each device holds a long-poll or websocket connection to a notification service. When a file under the account changes, the metadata is updated and the notification service pushes a small "something changed" signal — never the file bytes. The device then pulls the file's new ordered chunk-hash list from the metadata service, diffs it against the list it already has locally, and downloads only the chunks it is missing from the blob store, served through a CDN, before reassembling the file in order. Whether the device was one edit behind or a week offline, it is the same cheap diff of two hash lists.

How are conflicts and offline edits handled?

Every change is committed against the version the client last saw. For a single writer, that is a clean linear update that simply notifies the other devices to pull the delta. When two devices edit the same file while both are offline, each commits against the same base version, so on reconnect the server sees two divergent children of that version — a genuine conflict. Rather than silently overwrite one with the other (which would destroy real work), it keeps both: the original and a conflicted copy named for the second device, leaving the person to merge them. Version history is retained throughout, and because uploads are chunked, a dropped connection resumes at the next chunk rather than restarting.

How do I practise a system design interview out loud?

Practise it on Zynter

You can read what chunking and delta sync mean. The round is won on reasoning through sync efficiency out loud.

Pick the File Storage and Sync round, draw the metadata-plane, data-plane and notification design on the canvas, and defend it out loud to a voice interviewer that keeps asking "you change one byte in a 1 GB file — what moves?" and "two devices edit offline — who wins?" — then read the debrief. Zynter.ai is on-demand mock interviews modelled on real company loops, with 150+ rounds across 20 companies including the HLD system design track (Sep 2026).

Practise the File Storage and Sync round →
Browse all interview tracks

Design a real-time analytics system: the stream-processing walkthrough

Gowtham Potureddi — Mon, 19 Oct 2026 03:59:42 +0000

Design a real-time analytics system: the stream-processing walkthrough

The request to design a real-time analytics system sounds like a reporting feature — show some live numbers on a dashboard — and that framing is the trap. Picture it as a table you query on demand and you reach for a database and a GROUP BY; picture it as a firehose of events arriving a billion a minute, each one needing to move a counter that a dashboard reads a few seconds later, and it becomes one of the defining streaming problems in distributed systems. This is one of the most revealing real-time analytics system design prompts because the hard part is not storing the data — it is that you can never afford to scan the raw events when the dashboard loads. The numbers have to be computed as the data arrives and served pre-aggregated.

The round turns on one structural insight. "Show live metrics" hides the fact that the input is unbounded and bursty — it never ends, and it spikes without warning — so the only workable shape is a pipeline that aggregates continuously: ingest → process → store → serve. Raw events pour into a durable log; a stream processor rolls them up into windowed aggregates the instant they land; those rollups go to a store tuned to answer a dashboard query in milliseconds. Say that spine out loud and the system design interview becomes three decisions inside it: how to absorb the firehose without dropping data, how to aggregate a never-ending stream correctly when events arrive late and out of order, and how to serve queries sub-second over an enormous history while the numbers stay trustworthy. This walkthrough follows the path a strong candidate draws on the whiteboard — requirements, estimate, API and data model, high-level design, then the deep dives — naming the follow-up the interviewer uses at each step to tell a memorised answer from real understanding.

How the real-time analytics round is actually run

A real-time analytics round runs about 60 minutes on a shared canvas — you draw the boxes and arrows while you talk, and the interviewer interrupts. The extra time over a 45-minute round is not slack; it is because this problem has three substantial deep dives that each deserve real minutes, and a weak candidate spends the hour drawing one giant pipeline while a strong one budgets it across ingestion, aggregation and serving. The one-line problem opens onto deep water fast: the moment you draw "events go into a thing that counts them," the question becomes what counts as the right count, and every answer after that compounds from how you handle time, lateness and scale.

The interviewer rarely lets "we aggregate the events" stand. "Count the unique users in the last five minutes across a billion events a minute — exactly, or is approximate OK? Walk me through where that number actually gets computed and stored." That question — correctness and cost under a real firehose — is the one a copied answer can never rehearse, and the one this round is really testing.

The rounds here are modelled on how the loop runs, not scraped from any candidate's recall. What matters for prep is the shape: a blank canvas, a 60-minute clock, and a follow-up after every decision you make.

The five-step framework for any HLD round

Every high-level design answer fits the same spine. Say it out loud at the start so the interviewer knows you have a plan, then walk it:

Clarify requirements — functional and non-functional, and what you are explicitly not building.
Estimate — events per second and the burst factor versus query volume, to justify every later choice.
High-level design — the boxes and arrows: producers, the ingestion log, the stream processor, the serving store, and the query layer.
Deep dive — the two or three decisions that actually decide this system.
Follow-ups — bottlenecks, failure modes, and what you would change at ten times the scale.

What the debrief measures

The score is not "right or wrong design." A good HLD debrief reads on four dimensions, and every move below maps to one: problem solving (did you reframe it as pre-aggregate a stream, don't scan raw events, and reach for windows and approximation), communication (did you say in one sentence why approximate counts are fine for a live dashboard but a batch layer earns the exact numbers), technical execution (a partitioned log, a stream processor doing event-time windows with watermarks, rollups in an OLAP store, at-least-once plus idempotent writes), and time management (did you spend your 60 minutes across ingestion, aggregation and serving, not sink the hour into watermark edge cases). Reading a walkthrough teaches the design; it does not teach you to deliver it on the clock while someone pushes back.

Step 1 — Requirements: what a real-time analytics system must do

Spend the first few minutes here. Jumping to boxes before you have scoped the problem is the fastest way to design the wrong system.

Type	Requirement
Functional	Ingest a high-volume stream of events; compute aggregate metrics per key over time windows (counts, sums, distinct counts, top-K); serve live dashboards and ad-hoc queries over those metrics with low latency; support both a recent real-time view and a historical view.
Functional (optional)	Alerting / anomaly detection on the metrics, raw-event drill-down, custom user-defined metrics, exactly-once exact reporting for billing — call these out, then scope most of them for later.
Non-functional	Freshness — metrics reflect reality within seconds; the pipeline is write/aggregate-heavy and read-light; it scales horizontally to a firehose that bursts without warning; nothing is silently dropped under load; durable and highly available; dashboard queries return in well under a second.

The sentence that earns points: "This is a streaming aggregation problem, not reporting-over-a-table — I can't scan raw events per dashboard load at this volume, so I pre-aggregate the stream as it arrives and serve the rollups, and I'll decide per metric whether approximate-and-fast or exact-and-slightly-delayed is the requirement." Say that and you have framed the entire design before drawing a box.

Step 2 — Capacity estimation (back of the envelope)

Estimation here is about proving one thing: the load is a continuous write/aggregate stream, not a read workload — and that one asymmetry drives every later choice.

Quantity	Assumption	Result
Event rate	very high and bursty — say ~1M–1B events/sec at peak, spiking on events like a flash sale	the system is write/aggregate-bound; it must absorb bursts without dropping data
Query rate	low — a handful of dashboards and analysts, maybe tens to hundreds of queries/sec	read-light — so you can afford to pre-compute heavily and serve cheap reads
Raw retention	storing every raw event forever is enormous (petabytes)	roll up and expire raw — keep fine-grained rollups hot, coarsen or drop old raw
Unit of work	one metric for one key over one time window	the (key, window) tuple is what you partition on and pre-aggregate — the whole design orbits it

Two conclusions fall out, and you should say both out loud. First, because writes dwarf reads, you pre-compute aggressively: do the expensive aggregation once as data streams in, so every dashboard read is a cheap lookup of a rollup rather than a scan. Second, there are two regimes you must name: freshness (a live dashboard wants seconds-old numbers and can tolerate a small, bounded approximation) versus correctness (billing or official reporting wants exact numbers and can tolerate minutes of delay). Deciding which a given metric needs is what later justifies HyperLogLog over exact counting and lambda over a single pipeline. You have now pointed the interview at the real deep dives — ingestion, aggregation, and serving — before anyone asked.

Step 3 — API and data model

The API is deliberately small: producers push events in, consumers read pre-aggregated metrics out.

Operation	Shape
`ingest_event(event)`	accepts one event `(timestamp, type, key, dimensions, value)`; fire-and-forget, appended to the log.
`query_metric(metric, time_range, group_by, filters)`	reads pre-aggregated rollups for a metric over a time range, grouped and filtered.
`stream_metric(metric, filters)`	subscribes a live dashboard tile to the latest window as it closes.

The data model separates the raw truth you can replay from the rollups you actually serve:

Entity	Notes
`raw_event`	`(event_time, type, key, dimensions, value)` — the append-only log, short retention; the replay fuel for reprocessing, not what dashboards read.
`rollup`	`(metric, key, window_start, granularity, measures)` — the pre-aggregated result per key per window (count, sum, HLL sketch, top-K); this is the served source of truth.
`metric_definition`	how a metric is derived from events: which field, which aggregation, which windows and granularities to materialise.

The point to state: raw events are kept only long enough to replay and reprocess; the rollups are the served truth, and they are what the storage layer is built to answer fast.

Step 4 — High-level design: ingest, process, store, serve

Now the boxes. Events flow left to right through four stages, with a batch path on the side for exact numbers:

Producers and ingestion collector: clients, services and edge emit events to a thin collector that validates and forwards — it does no aggregation, just gets events onto the log fast.
Ingestion log (Kafka): a durable, partitioned append-only log is the buffer between producers and processing. It decouples the two, absorbs bursts, and is replayable.
Stream processor (Flink / Spark Structured Streaming): consumes the log partitions and computes windowed aggregates per key — this is where the real work happens.
Serving store (OLAP / time-series — Druid / Pinot / ClickHouse): holds the pre-aggregated rollups in a columnar, pre-rolled layout built for fast range and group-by queries.
Query service and dashboards: read rollups from the serving store; a live subscription pushes each window to dashboard tiles as it closes.
Batch layer (optional, for exactness): reprocesses the raw log on a schedule to produce exact numbers that reconcile the fast approximate layer.
Sharding: everything partitions by key — all events for a key land on one partition, so aggregation for that key is ordered and local.

Say explicitly that the design's whole job is to move the aggregation off the read path: pre-aggregate as data arrives so a dashboard query is a lookup of a rollup, never a scan of raw events. Naming that — a partitioned log feeding a stream processor that rolls up into an OLAP store — is the signal the interviewer is listening for.

Deep dive: ingesting the event firehose

Start at the front door, because if ingestion drops data the rest of the system is computing wrong numbers confidently. The follow-up is the spike: traffic jumps ten times in a flash sale — what happens to the events you can't process fast enough?

The answer is to put a durable, partitioned append log (Kafka) between producers and the stream processor, never to let producers write straight into the aggregator:

Decouple producers from consumers: producers only have to append to the log, fast and fire-and-forget; the processor consumes at its own pace. Neither blocks the other.
Absorb bursts as lag, not loss: when the firehose spikes past the processor's throughput, events pile up in the log and the processor falls behind — back-pressure becomes consumer lag, not dropped data. It catches up when the spike passes, because the data is safely durable.
Replayable: because the log retains events with offsets, you can rewind and reprocess — essential for fixing a bad aggregation, backfilling a new metric, or recovering a crashed processor from its last checkpoint.
Partition by key: the log is split into partitions keyed by the aggregation key, so all events for a key land in one partition in order, and the processor scales by assigning partitions across workers. Ordering is guaranteed per partition, not globally — which is all windowed aggregation per key needs.

The point to state plainly: the log turns a scary, unbounded, bursty input into something the rest of the system can consume calmly and re-consume if it has to. A spike is not an outage; it is lag that drains.

"Traffic spikes ten times in a flash sale — what happens to events you can't process fast enough?" Producers keep appending to the partitioned log, which is durable, so nothing is dropped — the stream processor simply falls behind and its consumer lag grows. When the spike passes, it catches up by reading the backlog; the dashboard is a few seconds staler for a while, but no event is lost and no count is wrong. The log absorbing the burst is exactly why I don't let producers write to the aggregator directly.

System Design
HLD · Media & analytics · 60 min
Design a real-time analytics system out loud, with follow-ups

Practise on Zynter →

Deep dive: stream processing, windows and approximation

Ingestion gets events in safely; this decides what the numbers actually are. It is the heart of the round and the richest source of follow-ups, because it is where correctness lives. The follow-up is the one that separates memorised answers from real ones: an event arrives two minutes late, after its window already closed — what happens?

The processor computes windowed aggregates — a metric per key over a bounded slice of time — and three decisions make them correct:

Tumbling vs sliding windows: tumbling windows are fixed and non-overlapping (every minute, a fresh bucket) — the default for dashboards; sliding windows overlap (a trailing five-minute count updated every minute) when you need a smooth moving metric. Say which and why.
Event time, not processing time: bucket each event by when it actually happened (its event timestamp), not when it reached the processor. A mobile client offline for a minute sends events whose event time is a minute old; counting them by arrival time would put them in the wrong window and make every historical number drift.
Watermarks close windows: since you aggregate by event time but events arrive out of order, you need a signal to decide a window is done. A watermark is a heuristic — "I believe I've now seen all events with timestamps up to time T" — that lets the processor close a window and emit its aggregate. It is a deliberate trade between waiting longer (more correct) and emitting sooner (fresher).
Late events past the watermark: an event that lands after its window closed is handled by an explicit policy you must name — drop it (fine for a live dashboard), route it to a side output for later reconciliation, or re-open and correct the window (needed for exact numbers). Never pretend late events don't happen.

Then the scale problem. At a billion events a minute, some aggregates won't fit in memory if computed exactly:

Approximate distinct counts (HyperLogLog): counting unique users exactly means holding every id you've seen — gigabytes per window. A HyperLogLog sketch estimates cardinality in a couple of kilobytes with a small bounded error (~2%), and sketches merge, so per-partition sketches combine into a global count. For a live "unique users" tile, that trade is almost always right.
Heavy hitters (count-min sketch): to find the top-K keys (hottest pages, biggest spenders) without a per-key counter for millions of keys, a count-min sketch estimates frequencies in fixed memory.
Emit rollups: the processor writes pre-aggregated rollups — (metric, key, window, measures) — downstream, so the serving store never sees raw events.

The sentence that shows range: for a live dashboard I'll accept a HyperLogLog estimate within a couple of percent because freshness matters more than the last digit; if the same number feeds billing, I run a batch job over the raw log to get it exact and reconcile. That is the freshness-versus-correctness trade the round is testing.

"An event arrives two minutes late, after its window already closed — what happens?" It depends on the policy I chose, and I'd state it: aggregate by event time, use a watermark to decide a window is complete, and for anything past the watermark either drop it (acceptable for a live dashboard), send it to a side output to reconcile later, or re-open the window and emit a correction if the metric must be exact. The watermark is a tunable trade between freshness and completeness — I don't pretend events arrive in order.

System Design
HLD · Media & analytics · 60 min
Defend event-time windows and watermarks out loud

Practise on Zynter →

Deep dive: storage, serving and correctness (lambda vs kappa)

Aggregation produces the numbers; this decides how a dashboard reads them in under a second over a huge history, and how you keep them correct. The follow-up is the one about scale on the read side: the dashboard must render in under a second over a trillion rows — how?

The serving layer is an OLAP / time-series store (Druid, Pinot or ClickHouse), not a general-purpose transactional database, and the reasons are specific:

Pre-aggregated and columnar: it stores the rollups, already grouped by key and window, in a columnar layout, so a range + group-by query touches only the relevant columns and segments — not a trillion raw rows. The expensive work was done once on the write path.
Time-partitioned, hot and cold: data is partitioned by time, so a query for "last hour" scans a tiny recent segment; older data is rolled up to a coarser granularity (minutes → hours → days) and eventually expired, keeping the hot set small and fast.
Built for this access pattern: these stores are tuned exactly for "aggregate a metric across a time range, grouped by a dimension," which is every analytics dashboard query, so they answer sub-second where a row store would table-scan.

Then correctness at the architecture level — name the two shapes and pick one:

Lambda architecture: run a speed layer (the stream pipeline — fast, approximate) beside a batch layer (reprocesses the raw log periodically for exact numbers), and merge them at query time (recent from the speed layer, settled history from batch). It gives you both freshness and exactness, at the cost of two codebases computing the same logic twice.
Kappa architecture: keep one streaming pipeline and, when you need to reprocess (a bug, a new metric, a correction), replay the log through it rather than maintaining a separate batch system. Simpler and less duplication; it leans on the log being replayable, which it is.

Finally, delivery semantics, because duplicates corrupt counts:

Exactly-once or effectively-once: the processor's checkpointing can give exactly-once within the pipeline; where it can't, use at-least-once delivery plus idempotent writes — an upsert keyed by (metric, key, window) — so re-processing the same event or replaying after a crash overwrites rather than adds, and a duplicate never double-counts.

The point to state plainly: the read path is fast because all the aggregation already happened on the write path, and the system stays correct because the raw log is replayable and the writes are idempotent — a crash or a correction is just a reprocess, not a lost or doubled number.

The follow-ups that decide the real-time analytics round

Scan the probes from each deep dive and they rhyme. Master these five and you are ready for a version of the question that is not drawn exactly like this one.

"Why not just run a GROUP BY over the raw events when the dashboard loads?" → Because at a billion events a minute that scan is impossibly slow and expensive per load. You pre-aggregate the stream as it arrives and serve cheap rollups; the read becomes a lookup, not a scan. (problem solving)
"Exact or approximate counts?" → Approximate for live dashboards — HyperLogLog gives a distinct count within a couple of percent in kilobytes, which beats storing every id; exact only where it must be (billing), computed by a batch job over the raw log and reconciled. State the freshness-versus-correctness trade. (communication)
"An event arrives late — what happens?" → Aggregate by event time, close windows on a watermark, and for anything past it apply a stated policy: drop, side-output to reconcile, or re-open and correct. The watermark trades freshness against completeness. (technical execution)
"The dashboard must render sub-second over a trillion rows — how?" → Serve pre-aggregated, time-partitioned, columnar rollups from an OLAP store; the aggregation already happened on the write path, so the query touches tiny recent segments, not raw rows. (technical execution)
"How do you keep numbers correct across crashes and reprocessing?" → At-least-once plus idempotent upserts keyed by (metric, key, window) so duplicates never double-count, a replayable log so reprocessing is a rewind, and lambda or kappa to reconcile the exact numbers. (problem solving)

Each maps to a debrief dimension. Reading this list teaches you the answers; it does not teach you to deliver them while someone interrupts — that only comes from saying them out loud.

How to prepare: a one-week plan

You do not need fifty systems. You need this one cold and the framework automatic, so the next "design X" is just new nouns in the same five steps.

Days 1–2: Learn the five-step framework until it is reflex. Do the real-time analytics system end to end on paper — requirements, estimate, API, data model, and the ingest/process/store/serve boxes.
Days 3–4: Drill the aggregation core: tumbling vs sliding windows, event time vs processing time, watermarks and late-event policy, and HyperLogLog vs exact counting. Say each tradeoff in one sentence.
Days 5–6: Own serving and correctness — why an OLAP store answers sub-second, lambda vs kappa, and at-least-once plus idempotent writes. Answer each of the five follow-ups out loud.
Day 7: A full timed 60-minute round, narrating the whole way, with someone (or something) interrupting. This is the rep that counts.

This post is the deep walkthrough behind one row of the broader Top 25 system design interview questions — once the real-time analytics pipeline is automatic, the same spine carries the rest of the list.

Frequently asked questions

How do I design a real-time analytics system step by step?

Follow the five-step HLD framework. Clarify requirements (ingest a high-volume event stream, compute windowed aggregate metrics per key, serve live dashboards and ad-hoc queries with seconds-level freshness, and decide per metric whether approximate-and-fast or exact-and-delayed is needed); estimate to show the load is write/aggregate-heavy and read-light, that raw retention is huge so you roll up and expire raw, and that the unit of work is the (key, window) tuple; define the small API (ingest_event, query_metric, stream_metric) over a raw-event log plus a rollup model; draw the design (producers → partitioned Kafka log → stream processor → OLAP serving store → query service, with a batch layer for exact numbers); then deep-dive ingestion, stream processing with windows and approximation, and storage/serving with lambda vs kappa. Finish on the follow-ups about late events and sub-second reads.

What is the difference between stream processing and batch processing here?

Stream processing aggregates events continuously the moment they arrive, so metrics are fresh within seconds but are computed on incomplete, out-of-order data and often use approximations. Batch processing reprocesses a complete, bounded set of raw events on a schedule, so it is slower but can produce exact numbers and backfill new metrics over all of history. A real-time analytics system usually needs both: the stream pipeline for the live dashboard, and a batch pass (or a replay through the same pipeline) to settle exact figures. The lambda architecture runs them side by side and merges at query time; the kappa architecture keeps one streaming pipeline and reprocesses by replaying the log.

What is a watermark, and how are late events handled?

A watermark is the stream processor's heuristic estimate that it has now seen all events with event timestamps up to some time T, which lets it close a time window and emit that window's aggregate. Because you bucket events by when they happened (event time) rather than when they arrived, and because events arrive out of order, you need this signal to decide a window is complete. An event that arrives after its window's watermark has passed is a late event, and you handle it with an explicit policy: drop it (acceptable for a live dashboard), route it to a side output to reconcile later, or re-open the window and emit a correction (for metrics that must be exact). The watermark is a tunable trade-off between freshness (emit sooner) and completeness (wait longer).

How do you count unique users across billions of events without running out of memory?

Use a probabilistic data structure instead of storing every id. A HyperLogLog sketch estimates the number of distinct values (cardinality) using only a couple of kilobytes per window, with a small bounded error of roughly two percent, where an exact set would need memory proportional to the number of unique users — gigabytes at this scale. HyperLogLog sketches also merge, so each partition computes its own sketch and they combine into a global distinct count. For finding the heaviest keys (top-K hot pages or users), a count-min sketch estimates frequencies in fixed memory. You accept a small, bounded approximation for live metrics because freshness matters more than the last digit; where an exact number is required, a batch job over the raw log produces it.

What is the difference between the lambda and kappa architectures?

Both aim to serve fresh metrics while still being able to produce exact, corrected numbers. The lambda architecture runs two layers: a speed layer (the real-time stream pipeline, fast but approximate) and a batch layer (reprocesses the raw log for exact results), merged at query time — powerful but it means maintaining two codebases that implement the same aggregation logic twice. The kappa architecture keeps a single streaming pipeline and, whenever it needs to reprocess for a correction or a new metric, replays the retained log through that one pipeline — simpler, with no duplicated logic, relying on the log being durable and replayable. Pick kappa for simplicity when one pipeline can meet the latency and correctness needs; pick lambda when a separate heavy batch computation genuinely earns its keep.

How do I practise a system design interview out loud?

Practise it on Zynter

You can read what a watermark is. The round is won on defending the trade-offs out loud.

Pick the Real-Time Analytics round, draw the ingest-process-store-serve pipeline on the canvas, and defend it out loud to a voice interviewer that keeps asking "exact or approximate — and why?" and "an event arrives late — what happens?" — then read the debrief. Zynter.ai is on-demand mock interviews modelled on real company loops, with 150+ rounds across 20 companies including the HLD system design track (Sep 2026).

Practise the Real-Time Analytics round →
Browse all interview tracks

Design a web search engine: the system design interview walkthrough

Gowtham Potureddi — Mon, 19 Oct 2026 03:47:46 +0000

Design a web search engine: the system design interview walkthrough

The request to design a web search engine sounds impossibly large — "build Google" — and that size is exactly the trap. The sentence hides three separate systems: a crawler that discovers pages, an indexer that turns them into something searchable, and a serving layer that answers a query in the blink of an eye. A strong candidate says that out loud in the first minute, scopes the crawler to its own problem, and names what this round is really about: given a corpus that has already been crawled, how do you answer a text query against billions of documents in well under a second and return the best results, not just the matching ones. That reframe — search engine system design is a top-K retrieval problem, not a crawling problem — is the move that turns an unanswerable prompt into a 45-minute design.

Underneath the reframe is one data structure and one hard operation. The data structure is the inverted index: instead of asking "what words does this document contain," you flip it to "what documents contain this word," so a query becomes a lookup, not a scan. The hard operation is doing that lookup across an index far too big for one machine, which forces you to shard by document and answer every query as a scatter-gather — fan the query out to every shard in parallel, let each return its local best, and merge. Get that spine — an offline pipeline builds an inverted index, the index is sharded by document and queried by scatter-gather, and a ranking function decides the order — and the rest of the system design interview is deciding how the index is built, how the fan-out stays fast, and how you rank two matching pages against each other. This walkthrough follows the path a strong candidate draws on the whiteboard — requirements, estimate, API and data model, high-level design, then the deep dives — naming the follow-up the interviewer uses at each step to tell a memorised answer from real understanding.

How the web search round is actually run

A web search round runs about 45 minutes on a shared canvas — you draw the boxes and arrows while you talk, and the interviewer interrupts. It is a favourite because the one-line problem is so obviously too big that it immediately tests whether you can scope: the candidates who try to design the crawler, the ranking machine-learning model, and the serving layer all at once run out of clock with nothing finished. The ones who score say "three systems; I'll scope the crawler out and design indexing and serving," and spend their minutes where the depth is.

The interviewer rarely lets "I'd build an index and search it" stand. "Your corpus is a hundred billion documents and the index is tens of terabytes — it cannot live on one machine. How do you split it, and how does a single query still come back in under a second?" That question — retrieval at a scale no single node can hold — is the one a copied answer can never rehearse, and the one this round is really testing.

The rounds here are modelled on how the loop runs, not scraped from any candidate's recall. What matters for prep is the shape: a blank canvas, a prompt too big to take literally, and a follow-up after every decision you make.

The five-step framework for any HLD round

Every high-level design answer fits the same spine. Say it out loud at the start so the interviewer knows you have a plan, then walk it:

Clarify requirements — functional and non-functional, and what you are explicitly not building.
Estimate — corpus size and query volume, to justify why the index must be sharded and the query fanned out.
High-level design — the boxes and arrows: the offline indexing pipeline, the document-sharded query servers, the coordinator, and ranking.
Deep dive — the two or three decisions that actually decide this system.
Follow-ups — bottlenecks, failure modes, and what you would change at ten times the scale.

What the debrief measures

The score is not "right or wrong design." A good HLD debrief reads on four dimensions, and every move below maps to one: problem solving (did you reframe it as top-K retrieval over an inverted index and scope the crawler out), communication (did you say in one sentence why document-sharding beats term-sharding, and why retrieval and ranking are two separate phases), technical execution (an offline pipeline producing an inverted index, document shards with replicas, a coordinator merging per-shard top-K, and a ranker), and time management (did you spend your 45 minutes on the index, serving and ranking, not on the crawler or the search box UI). Reading a walkthrough teaches the design; it does not teach you to deliver it on the clock while someone pushes back.

Step 1 — Requirements: what a web search engine must do

Spend the first few minutes here. Jumping to boxes before you have scoped the problem is the fastest way to design the wrong system — and for this prompt, scoping is the first scored move.

Type	Requirement
Functional	Accept a free-text query and return a ranked list of relevant documents (url, title, snippet); support multi-term queries and phrase queries; results should be reasonably fresh.
Functional (optional)	Spelling correction, autocomplete, personalisation, image/news verticals, pagination — name them, then scope most of them for later.
Out of scope (say it)	The crawler that discovers and fetches pages is its own system — assume a crawled corpus exists.
Non-functional	Low latency — sub-second response — at very high QPS; scale to billions of documents; relevance quality (the right results near the top); high availability; freshness within a tolerable lag.

The sentence that earns points: "This is really three systems — crawl, index, serve — and this round is the serve half. Assume a crawled corpus; I'll design an inverted index, document-sharded query serving, and ranking, and treat the crawler as a separate problem." Say that and you have framed the entire design — and shown judgement — before drawing a box.

Step 2 — Capacity estimation (back of the envelope)

Estimation here is about proving two things: the index is far too big for one machine, and the query rate is far too high to recompute anything per request — so the index must be partitioned and the popular results cached.

Quantity	Assumption	Result
Corpus size	billions of documents, tens of terabytes of index	the index cannot fit on one machine — it must be sharded by document across many servers
Query volume	tens of thousands of queries per second, with a heavy-tailed distribution (a few queries are wildly popular)	replicas per shard for throughput, and a query cache for the popular tail
Per-query work	each query touches every shard to find its best local results	fan-out must be parallel; the slowest shard sets the tail latency
Freshness	the web changes constantly, but not every page every second	build the index offline in batch, add incremental segments for new/changed pages

Two conclusions fall out, and you should say both out loud. First, there are two regimes that barely touch: offline indexing is a throughput problem (process the whole corpus into an index), while online serving is a latency problem (answer one query fast) — design them separately. Second, because no machine can hold the index and no request can afford a scan, the system is defined by partitioning the index by document and fanning each query out in parallel to all partitions. You have now pointed the interview at the real deep dives — building the index, serving the query across shards, and ranking — before anyone asked.

Step 3 — API and data model

The external API is tiny — one endpoint. The interesting model is internal: the inverted index and the document store.

Operation	Shape
`search(query, page)`	parse the query, retrieve matching documents, rank them, and return a page of results (url, title, snippet).
`get_document(doc_id)`	internal lookup of a document's metadata for rendering a result.

The data model has three parts. The inverted index is the heart; the document store holds what you show the user; the query cache is an optimisation:

Entity	Notes
`inverted_index`	`term -> posting list`, where each posting is `(doc_id, positions, term_frequency)`. Positions let you answer phrase/proximity queries; term frequency feeds ranking. This is immutable once built — new data arrives as new segments.
`document`	`doc_id -> (url, title, snippet, authority_score, length, last_crawled)` — the metadata you render and the query-independent signals you rank with.
`query_cache`	`normalised_query -> ranked result page`, aged against a freshness budget — absorbs the popular tail of queries.

Step 4 — High-level design: indexing pipeline, query serving and ranking

Now the boxes. Split the picture into the offline path that builds the index and the online path that serves a query:

Indexing pipeline (offline, batch): reads the crawled corpus, tokenises and normalises each document, and builds the inverted index. It is a throughput job (MapReduce-style) that produces an immutable index shipped out to the query servers.
Query servers, sharded by document: the index is split into shards, each holding the full inverted index over a slice of the corpus. Every shard is replicated for throughput and availability.
Coordinator / aggregator: receives the parsed query, scatter-gathers it to every shard in parallel, collects each shard's local top-K, and merges them into a global top-K.
Ranking: a cheap retrieve inside each shard, then an expensive rerank of the merged candidates using text relevance plus query-independent authority.
Query cache: sits in front of the coordinator and returns the stored ranked page for popular queries without touching the shards.
Document store: holds url/title/snippet/authority for rendering results and for ranking.

Say explicitly that the document is the unit of partitioning: each shard can answer a whole query over its slice by itself, so the coordinator never ships posting lists between nodes — it only merges small top-K lists. Naming that — an offline-built inverted index, document-sharded and queried by scatter-gather, then reranked and cached — is a signal the interviewer is listening for.

Deep dive: building the inverted index

This is the structure the whole system is built on, so expect the interviewer to make you build it from a raw document. The follow-up is concrete: you have the text of a page — walk me from that to something a query can hit in milliseconds.

The answer is a pipeline that flips documents into terms. For each crawled document:

Tokenise: split the text into terms (words), handling punctuation and case.
Normalise: lowercase, stem (so "running" and "run" match), and drop very common stopwords — so queries match regardless of surface form.
Emit postings: for each term, record a posting (doc_id, positions, term_frequency). Positions are what later let you answer a phrase query ("brown fox" as an ordered pair, not two separate words).
Group by term: invert and collect every posting for a term into its posting list. The result is the inverted index: term -> [posting, posting, ...].

Two properties decide how you operate it. First, this is an offline batch job — a throughput problem over the whole corpus, naturally a MapReduce-style map (document to postings) and reduce (group by term). Second, the built index is treated as immutable: you do not edit posting lists in place under live queries. Freshness comes from building incremental segments — small indexes over new or changed pages — and merging them into the query path, so a query reads the main index plus the recent segments. State the trade-off plainly: a bigger batch cadence is cheaper but staler; incremental segments buy freshness at the cost of more merge work and more segments to search.

"How do you keep the index fresh without rebuilding it from scratch every time a page changes?" You don't rebuild. The main index is immutable and built in batch; new and changed pages are indexed into small incremental segments that are merged into the serving path, so a query reads the big index plus a handful of recent segments. Periodically the segments are compacted back into the main index. Freshness is a cadence-versus-cost dial, not a live edit.

System Design
HLD · Search & discovery · 45 min
Build the inverted index out loud, with follow-ups

Practise on Zynter →

Deep dive: query serving at scale (document sharding and scatter-gather)

This is the decision the scale follow-up forces. The probe: the index is sharded across a thousand machines — how does one query use all of them and still return in under a second?

Start with how a single query works on one index. Parse it into terms; for each term, fetch its posting list; then intersect the lists (for an AND query, keep only documents that appear in every term's list) to get the candidate set. Now scale it:

Shard by document: split the corpus into slices and give each shard the full inverted index over its slice. Crucially, a shard can answer the whole multi-term query over its own documents with no help from other shards.
Scatter-gather: the coordinator sends the query to every shard in parallel. Each shard retrieves its candidates, ranks them locally, and returns only its local top-K (say, its best 100). The coordinator merges the per-shard top-Ks into the global top-K.
Replicate each shard: multiple replicas per shard serve the QPS and provide availability; the coordinator can send hedged requests so one slow replica doesn't drag the whole query.
Why document-sharding, not term-sharding: if you instead split by term (each node owns some terms' posting lists), a multi-term query must ship huge posting lists between nodes to intersect them, and popular terms turn their node into a hotspot. Document-sharding keeps every query local to each shard, makes fan-out uniform, and lets you grow by simply adding shards.

The point to state plainly: the coordinator never moves posting lists around — it only fans out the query and merges small top-K lists, so the network cost per query is tiny and constant. The latency is set by the slowest shard, which is why replicas and hedging matter. This is the same scatter-gather shape behind most large search and analytics systems.

"A query has to touch every shard — how is that fast?" Because every shard works in parallel and each only returns its local top-K — a few hundred bytes — not raw posting lists. The coordinator fans out once, waits for the shards (hedging around slow replicas), and merges small sorted lists into the global top results. Fan-out is parallel, the per-shard work is bounded by top-K, and the network payload is tiny; the tail latency is the slowest shard, so we replicate and hedge.

System Design
HLD · Search & discovery · 45 min
Defend the scatter-gather sharding out loud

Practise on Zynter →

Deep dive: ranking, relevance and caching

Retrieval finds the documents that match; ranking decides which comes first — and this is where "which one is at the top, and why" is decided. The follow-up is the comparison: two pages both contain every query word — how do you order them?

The answer is a score that blends what the query says with what the corpus and the web say about each document:

Text relevance (query-dependent): a function of how well the document matches the query terms — TF-IDF or BM25: a term counts for more when it appears often in this document (term frequency) and is rare across the corpus (inverse document frequency), with BM25 adding length normalisation so long documents don't win by sheer size.
Authority and quality (query-independent): signals computed ahead of time — a link-based authority score (the PageRank-style idea that a page linked to by many good pages is itself good), freshness, and quality signals. These are stored per document and don't depend on the query.
Two-phase retrieve-then-rerank: each shard does a cheap retrieve to a few thousand candidates using a simple score; the coordinator then reranks the merged top candidates with the expensive full feature set (including authority and, in a real system, learned ranking). You only pay the expensive model on a small, promising set.
Caching: because the query distribution is heavy-tailed, cache the ranked results of popular queries so they skip the shards entirely. Age the cache against a freshness budget — the trade-off is serving a slightly stale top result cheaply versus recomputing for freshness.

The point to state plainly: matching and ordering are two different problems. Retrieval is about correctness (did we find every candidate) and is cheap and parallel; ranking is about quality (is the best one first) and is where the expensive signals live, applied late to a small set. Say that split out loud and the follow-up about ordering answers itself.

"Two documents both match every word — which one is first, and why?" The one with the higher combined score. Text relevance (BM25 — the query terms are frequent in the document and rare across the corpus, normalised for length) says how well it matches; query-independent authority (a PageRank-like link score) and freshness say how much to trust it. We retrieve cheaply to a few thousand candidates per shard, merge, then rerank the top of that merged set with the full, expensive signals — so the ordering reflects both the match and the document's standing, without scoring billions of pages.

The follow-ups that decide the web search round

Scan the probes from each deep dive and they rhyme. Master these five and you are ready for a version of the question that is not drawn exactly like this one.

"Isn't this just building Google? Where do you start?" → It's three systems — crawl, index, serve. Scope the crawler out as its own problem and design the serve half: an inverted index, built offline, sharded by document, queried by scatter-gather, then ranked. (problem solving)
"The index is tens of terabytes — how do you split it?" → Shard by document: each shard holds the full inverted index over a slice of the corpus, so it can answer any query locally; replicate each shard for QPS and availability. (technical execution)
"A query touches every shard — how is that fast?" → Parallel scatter-gather; each shard returns only its local top-K, and the coordinator merges small sorted lists — tiny network payload. Tail latency is the slowest shard, so we hedge across replicas. (technical execution)
"Why document sharding and not term sharding?" → Term sharding forces multi-term queries to ship big posting lists between nodes and turns popular terms into hotspots; document sharding keeps every query local to each shard and scales by adding shards. (communication)
"Two pages both match — which ranks first?" → The higher combined score: BM25 text relevance plus query-independent authority (PageRank-like) and freshness, applied as a cheap retrieve then an expensive rerank of the merged top candidates. (problem solving)

Each maps to a debrief dimension. Reading this list teaches you the answers; it does not teach you to deliver them while someone interrupts — that only comes from saying them out loud.

How to prepare: a one-week plan

You do not need fifty systems. You need this one cold and the framework automatic, so the next "design X" is just new nouns in the same five steps.

Days 1–2: Learn the five-step framework until it is reflex. Do the web search engine end to end on paper — requirements (scope the crawler out), estimate, API, data model, and the indexing/serving/ranking boxes.
Days 3–4: Drill the inverted index: tokenise, normalise, postings with positions, offline batch build, immutable index plus incremental segments for freshness. Say each step in one sentence.
Days 5–6: Own serving and ranking — document sharding, scatter-gather with per-shard top-K, why document beats term sharding, and BM25 + authority with two-phase retrieve-then-rerank and a query cache. Answer each of the five follow-ups out loud.
Day 7: A full timed 45-minute round, narrating the whole way, with someone (or something) interrupting. This is the rep that counts.

This post is the deep walkthrough behind one row of the broader Top 25 system design interview questions — once the web search engine is automatic, the same spine carries the rest of the list.

Frequently asked questions

How do I design a web search engine step by step?

Follow the five-step HLD framework. Clarify requirements (accept a text query and return a ranked list of relevant documents with url, title and snippet, support multi-term and phrase queries, stay reasonably fresh — and explicitly scope the crawler out as a separate system); estimate to show the index is far too big for one machine and the query rate too high to recompute per request, so the index is sharded by document and popular results are cached; define the small API (search(query, page)) over an inverted-index and document-store model; draw the design (an offline indexing pipeline building an immutable inverted index, document-sharded query servers with replicas, a coordinator that scatter-gathers and merges per-shard top-K, a ranking phase, and a query cache); then deep-dive building the inverted index, query serving across shards, and ranking. Finish on the follow-ups about scale, fan-out and ordering.

What is an inverted index?

An inverted index is the core data structure of a search engine. Instead of mapping each document to the words it contains, it maps each word (term) to the list of documents that contain it — the term's posting list, where each posting records a document id, the positions of the term in that document, and its term frequency. Positions let the engine answer phrase and proximity queries; term frequency feeds ranking. It is called "inverted" because it flips the natural document-to-terms relationship into terms-to-documents, which turns a query into a fast lookup and intersection of posting lists instead of a scan of every document.

How does a search engine serve a query across billions of documents?

It shards the index by document — each shard holds the full inverted index over a slice of the corpus — and answers every query as a scatter-gather. A coordinator parses the query, fans it out to all shards in parallel, and each shard retrieves and ranks its own candidates and returns only its local top-K. The coordinator merges those small per-shard top-K lists into the global top results, reranks them with the full scoring signals, and returns a page. Each shard is replicated for throughput and availability, and the coordinator hedges requests so one slow replica doesn't set the latency. Popular queries are served from a result cache without touching the shards at all.

Document sharding vs term sharding — which and why?

Document sharding. If you split the index by document, every shard can answer a whole multi-term query over its own slice locally, so the coordinator only merges small top-K lists and never ships posting lists between machines; fan-out is uniform and you scale by adding shards. If you split by term instead (each node owns some terms' posting lists), a multi-term query has to transfer large posting lists across the network to intersect them, and a popular term turns its node into a hotspot. Term partitioning can save some disk I/O for single-term queries, but for a general multi-term web search, document sharding is the standard choice.

How are search results ranked?

By a score that combines query-dependent and query-independent signals. The query-dependent part is text relevance — TF-IDF or BM25 — which rewards query terms that are frequent in the document and rare across the corpus, with length normalisation. The query-independent part is computed ahead of time per document: a link-based authority score (the PageRank idea that a page linked by many good pages is trustworthy), freshness, and quality signals. Serving is two-phase: each shard cheaply retrieves a few thousand candidates, the coordinator merges them, and only then does an expensive rerank with the full feature set run on the small merged set — so the best result rises to the top without scoring billions of pages per query.

How do I practise a system design interview out loud?

Practise it on Zynter

You can read what an inverted index is. The round is won on defending the scatter-gather out loud.

Pick the Web Search Engine round, draw the indexing pipeline, document-sharded serving and ranking on the canvas, and defend it out loud to a voice interviewer that keeps asking "the index is a hundred billion documents — how do you shard it?" and "two pages both match — which is first, and why?" — then read the debrief. Zynter.ai is on-demand mock interviews modelled on real company loops, with 150+ rounds across 20 companies including the HLD system design track (Sep 2026).

Practise the Web Search Engine round →
Browse all interview tracks

Design a CDN: the content delivery network system design walkthrough

Gowtham Potureddi — Mon, 19 Oct 2026 03:42:55 +0000

Design a CDN: the content delivery network system design walkthrough

The request to design a CDN sounds like a one-liner — put the files closer to the users — and that one line hides the whole interview. A content delivery network system design is not a file server with extra machines; it is a globally distributed read-through cache where a request from a phone in Mumbai should be answered by a server a few milliseconds away instead of crossing an ocean to your origin, and where the hard parts are the two problems nobody mentions in the one-liner: how a client is routed to the nearest healthy edge, and how a cached object stays correct — fresh, and invalidated the instant it changes — without a flood of misses stampeding the one origin behind it. Latency is physics: bytes crossing half the planet cost real milliseconds. The entire point of a CDN is to shorten that distance for the overwhelming majority of requests, so the caching problem and the geography problem are the same problem.

That reframe is the spine of the round. "Serve content faster" becomes answer as close to the user as possible, on a cache hit, and make the rare miss both cheap and safe for the origin. Everything after it follows: you spread edge servers across points of presence worldwide, you route each user to the best one, you decide how those edges fill with content and how long they trust it, and you make sure that when a video suddenly goes viral — or when the origin falls over — the edges absorb the storm instead of forwarding it. Get that framing out loud early and the rest of the system design interview is a series of defensible decisions rather than a scramble. This walkthrough follows the path a strong candidate draws on the whiteboard — requirements, estimate, API and data model, high-level design, then the deep dives — naming the follow-up the interviewer uses at each step to tell a memorised answer from real understanding.

How the CDN round is actually run

A CDN round runs about 45 minutes on a shared canvas — you draw the boxes and arrows while you talk, and the interviewer interrupts. It is a favourite because the one-line problem opens onto deep water fast: the moment you draw "edge servers near the users," the question becomes how does a given user reach the right edge and what happens on a cache miss, and every answer after that compounds from those two. The clock is a touch tighter than the hour-long rounds, so you have to spend your minutes on routing, freshness and origin protection, not on TLS handshakes or a billing model.

The interviewer rarely lets "edge servers cache the content" stand. "A video suddenly goes viral in one region — a million requests a minute for a file that isn't in that region's cache yet. What happens at the edge, and what happens to your origin?" That question — a cache-miss storm against a single origin — is the one a copied answer can never rehearse, and the one this round is really testing.

The five-step framework for any HLD round

Every high-level design answer fits the same spine. Say it out loud at the start so the interviewer knows you have a plan, then walk it:

Clarify requirements — functional and non-functional, and what you are explicitly not building.
Estimate — the read:write ratio, the target cache-hit ratio, and request volume per PoP, to justify every later choice.
High-level design — the boxes and arrows: the client, the routing layer, the edge PoPs, the regional/shield tier, and the origin.
Deep dive — the two or three decisions that actually decide this system.
Follow-ups — bottlenecks, failure modes, and what you would change at ten times the scale.

What the debrief measures

The score is not "right or wrong design." A good HLD debrief reads on four dimensions, and every move below maps to one: problem solving (did you reframe it as a distributed read-through cache and name routing and freshness as the two hard problems), communication (did you state the GeoDNS-versus-anycast trade-off and why versioned URLs beat a purge, each in a single sentence), technical execution (a PoP/edge topology with an origin-shield tier, TTL-based freshness, consistent hashing and LRU at the edge, request coalescing and serve-stale under stress), and time management (did you spend your 45 minutes on routing, freshness and origin offload, not on peripheral features). Reading a walkthrough teaches the design; it does not teach you to deliver it on the clock while someone pushes back.

Step 1 — Requirements: what a CDN must do

Spend the first few minutes here. Jumping to boxes before you have scoped the problem is the fastest way to design the wrong system.

Type	Requirement
Functional	Serve cached content (static assets and media) to users from a nearby location; fetch from the origin on a cache miss and cache it; honour per-object freshness (TTL / `Cache-Control`); support invalidation — explicit purge and versioned URLs; route each client to the nearest healthy PoP; terminate TLS at the edge.
Functional (optional)	Dynamic content acceleration, signed/expiring URLs, image resizing at the edge, edge compute, per-customer analytics — call these out, then scope most of them for later.
Non-functional	Low latency for users anywhere; very high read throughput; a high cache-hit ratio so most requests never leave the edge; protect and offload the origin (it should barely feel global traffic); high availability across PoPs (one PoP dying must not break the service); freshness is eventually consistent — a changed object propagates quickly, not atomically.

The sentence that earns points: "This is a globally distributed read-through cache — the win is answering near the user on a cache hit, and the two hard problems are routing a user to the nearest healthy edge and keeping cached objects fresh and invalidated without a miss storm hitting the single origin." Say that and you have framed the entire design before drawing a box.

Step 2 — Capacity estimation (back of the envelope)

Estimation here is about proving one thing: the cost is the miss, not the hit — hits are cheap and local, and the whole design exists to keep the miss rate low and the miss cheap.

Quantity	Assumption	Result
Read:write ratio	overwhelmingly reads — content is published rarely, read constantly	optimise the read path ruthlessly; writes (publishes/purges) are a slow control-plane concern
Cache-hit ratio	target 90%+ at the edge for cacheable content	only <10% of requests become misses — so the origin is sized for the miss stream, not total traffic
Requests per PoP	high, bursty, concentrated on a small set of hot objects	a Zipf-like popularity curve — a few objects are most of the traffic, so replicate hot objects and let the long tail be re-pulled
Edge storage	finite per edge; far smaller than the full catalogue	you cannot cache everything — you need an eviction policy (LRU) and the long tail lives at the origin

Two conclusions fall out, and you should say both out loud. First, hits are free and misses are expensive, so the architecture is one long effort to raise the hit ratio and to make each miss resolve with a single origin fetch — which points straight at a cache hierarchy. Second, popularity is skewed: a handful of hot objects dominate, so hot-object replication and herd control matter far more than uniform placement. You have now pointed the interview at the real deep dives — routing, freshness/invalidation, and origin offload — before anyone asked.

Step 3 — API and data model

The API is deliberately small: clients read objects, publishers write them to the origin, and the control plane invalidates.

Operation	Shape
`GET /{object}`	the hot path — served from the nearest edge; conditional reads use `If-None-Match: <etag>` so a revalidation can return `304 Not Modified`.
`PUT /{object}` (publish)	the publisher writes a new object (or version) to the origin; edges pick it up lazily on the next miss (pull) or via a push.
`PURGE /{path}`	control-plane invalidation — drop an object (or prefix) from every edge immediately.
versioned URL	`…/app.<content-hash>.js` — a new version is a new URL, so no invalidation is needed at all.

The data model is thin. The origin is the source of truth; the edge cache is derived and disposable:

Entity	Notes
`object`	`key`, `bytes`, `content_hash`, `Cache-Control`/`ttl`, `ETag`, `last_modified` — the asset and its freshness metadata.
`edge_cache_entry`	`(object_key, bytes, expires_at, last_access)` — a cached copy at one edge; `last_access` drives LRU eviction; ephemeral.
`routing_map`	PoP locations, health and load — used to pick the edge for a client.
`origin_mapping`	which origin backs which hostname/path, plus the shield tier in front of it.

Step 4 — High-level design: edges, the cache hierarchy and the origin

Now the boxes. A request is answered as close to the user as possible, and only the rare miss climbs the hierarchy toward a single origin:

Routing layer: decides which PoP serves a given client, using GeoDNS and/or anycast, and must be health- and load-aware so a dead or overloaded PoP is taken out of rotation.
Edge server (in a PoP): holds cached objects and answers on a cache hit. On a miss it fetches from the next tier up, caches the object (respecting TTL), and serves it. Evicts with LRU under finite storage.
Regional edge cache / origin shield: a mid-tier in front of the origin. Many edge misses for the same object collapse into one fetch here, so the origin sees a tiny, smooth fraction of global traffic.
Origin: the source of truth — your storage or application. Sized for the miss stream only, protected by the shield.
Control plane: config, TTLs, and purge commands; propagates invalidations out to the edges.
Feedback: PoP health and load signals flow back into the routing layer so routing follows reality, not a static map.

Say explicitly that this is a tiered read-through cache: the edge answers hits locally, a miss climbs edge → shield → origin and the object is cached on the way back, and the origin is deliberately shielded so a global audience feels like a trickle. Naming that tiering — and the fact that hits never leave the edge — is a signal the interviewer is listening for.

Deep dive: request routing — finding the nearest edge (GeoDNS vs anycast)

This is the first decision the round is really about. The follow-up is the geography: how does a user in Mumbai actually end up talking to a Mumbai edge, and what happens the moment that PoP dies?

There are two well-known mechanisms, and the strong answer names both, picks a combination, and justifies it:

	GeoDNS (DNS-based routing)	Anycast (BGP routing)
Idea	the CDN's authoritative DNS resolves the hostname to the IP of a nearby edge, chosen from the resolver's location, health and load	every PoP announces the same IP; the internet's BGP routing delivers the packet to the topologically nearest PoP
Load awareness	high — DNS can steer away from a hot PoP and weight responses	coarse — routing follows network topology, not your load
Failover speed	as slow as the DNS TTL (cached resolvers keep sending users to a dead edge until it expires)	near-instant — withdraw the route and traffic reroutes automatically
Precision	limited to the resolver, not the user (public resolvers can mislocate)	precise at the network level; but routes can flap and move sessions
Best for	load-aware steering, weighted rollouts	fast failover, DDoS absorption, a single stable IP

In practice you combine them: anycast to a region for a stable IP and instant failover, GeoDNS (or application-level steering) for finer, load-aware placement — and both must be health-aware, pulled from a live view of which PoPs are up and how loaded they are. Then say the one sentence that shows range: GeoDNS gives me precise, load-aware control but failover is bounded by the DNS TTL, while anycast gives near-instant failover and a single IP at the cost of coarse load control — so I'd lean anycast for resilience and layer DNS steering on top for load. That is the trade-off the round is testing.

"A user in Mumbai requests a file — how do they end up on the Mumbai edge, and what happens when that PoP goes down?" With GeoDNS, the CDN's authoritative DNS sees the request's rough location and returns the IP of a healthy nearby edge; with anycast, every PoP announces the same IP and BGP delivers the packet to the nearest one. When the PoP dies, anycast reroutes almost instantly because the route is withdrawn, while pure DNS failover waits for the TTL to expire — which is why real CDNs lean on anycast for failover and keep routing health- and load-aware.

System Design
HLD · Infrastructure · 45 min
Design a CDN out loud, with follow-ups

Practise on Zynter →

Deep dive: cache population, freshness and invalidation

Routing decides where a request lands; this decides what the edge holds and whether you can trust it. The follow-up is the update: you publish a new version of a file — how fast does every edge start serving it, and how do you make that happen?

Start with how an edge even fills. There are two models, and you should name both:

Pull (origin-pull / lazy): the edge caches an object on the first miss in that region. Simple, self-healing, and it never wastes storage on objects nobody wants — the first user in a region pays the miss, everyone after gets the hit. This is the default.
Push: the origin proactively pushes content to edges ahead of demand — useful for a known launch or a large static library where you don't want the first user anywhere to eat a cold miss. The cost is pushing objects that may never be requested.

Then freshness — how long an edge trusts what it holds:

TTL / Cache-Control: max-age sets how long an object is fresh; while fresh, it is served with zero origin contact.
On expiry, the edge revalidates cheaply: If-None-Match: <etag> (or If-Modified-Since), and the origin replies 304 Not Modified if nothing changed — a tiny response instead of re-downloading the object.
stale-while-revalidate serves the slightly stale copy instantly and refreshes it in the background, so users never wait on a revalidation.

Finally invalidation — forcing a change before TTL expiry — where the strong candidate shows judgement:

Explicit purge: a control-plane command drops an object (or prefix) from every edge. It works, but it is a global operation with a brief race until all edges have cleared, and it is easy to over-purge.
Versioned / fingerprinted URLs: put a content hash in the path (app.9f2c1a.js). A new version is a new URL that cannot collide with the cached old one, so the old object can be cached effectively forever and the switch is instant — no purge required. This is the cleanest cache-busting and the answer that scores.

Tie it together with the cache hierarchy: because misses collapse at the origin shield, even a cold object pulled by thousands of edges resolves to a handful of origin fetches, not thousands. Say it plainly: static assets get long TTLs and versioned URLs so updates are instant and the origin is barely touched; truly dynamic objects get short TTLs or explicit purges.

"You push a new version of a file — how fast does every edge serve it?" If I version the URL with a content hash, instantly: the new version is a new URL, so there's nothing to invalidate and the old one can stay cached. If I must keep the same URL, I issue a purge from the control plane to drop it from every edge, accepting a brief propagation race, or I rely on a short TTL so it refreshes on the next revalidation. For static assets I default to versioned URLs with long TTLs; that keeps updates instant and the origin cold.

System Design
HLD · Infrastructure · 45 min
Defend your freshness and invalidation model out loud

Practise on Zynter →

Deep dive: scale, hot content and origin offload

Routing and freshness keep a steady state healthy; this decides what happens under the two stresses that break a naive CDN — a viral object and a dead origin. The follow-up is the storm: a file goes viral in one region and it isn't cached there yet — what stops a million simultaneous misses from flattening your origin?

The answer is a stack of defences, each worth naming:

Object placement with consistent hashing: within a PoP, objects are spread across the edge servers by consistent hashing, so adding or removing a server moves a minimal set of keys rather than reshuffling everything — and so every edge agrees on which server owns a key.
Replicate hot objects: a Zipf-hot object is deliberately replicated to more servers so a single viral file doesn't melt one box; popularity, not a uniform hash, decides how many copies.
Request coalescing (the key defence): when many clients miss on the same object at once, the edge issues one origin fetch and makes everyone else wait on that single in-flight request. A million concurrent misses become one upstream fetch — this is what actually kills the thundering herd.
Origin shield: coalescing repeats at the shield tier, so even misses from many PoPs for the same object collapse to one origin fetch. The origin sees a trickle.
Serve stale on failure: if the origin is slow or down, edges serve the stale copy past its TTL rather than returning an error — availability beats strict freshness for cached content. The shield keeps retrying in the background.

Say the point plainly: the origin must never feel the crowd. Consistent hashing places objects, replication spreads the hot ones, coalescing and the shield fold a stampede into a single fetch, and serve-stale means an origin outage degrades to slightly-old content instead of an error page. That is how a CDN turns a viral spike or an origin failure into a non-event.

"The origin goes down — what do the edges serve?" They keep serving: on a miss or an expiry they serve the stale cached copy past its TTL rather than erroring, while the origin shield retries the origin in the background. Fresh objects are unaffected because they never touch the origin anyway. The design choice is explicit — for cached content, availability (serve slightly stale) beats strict freshness — so an origin outage degrades gracefully instead of becoming a global error.

The follow-ups that decide the CDN round

Scan the probes from each deep dive and they rhyme. Master these five and you are ready for a version of the question that is not drawn exactly like this one.

"How does a user reach the nearest edge, and what happens when a PoP dies?" → GeoDNS returns a nearby healthy edge IP (load-aware, but failover waits for the DNS TTL); anycast announces one IP from every PoP and BGP routes to the nearest (near-instant failover, coarser load control). Combine them and keep routing health-aware. (technical execution)
"Pull or push — how do edges get their content?" → Pull by default: cache on the first miss, self-healing, no wasted storage; push proactively only for known launches or large libraries where a cold first miss is unacceptable. (problem solving)
"You change a file — how do you invalidate it everywhere?" → Best: versioned/fingerprinted URLs, so a new version is a new URL and nothing needs purging; otherwise an explicit control-plane purge (global, with a brief race) or a short TTL. Default to versioned URLs with long TTLs. (communication)
"A file goes viral and isn't cached — what stops the origin from melting?" → Request coalescing (one in-flight origin fetch per key, everyone waits on it) plus the origin shield (misses from many PoPs collapse to one), with hot-object replication across edge servers. (technical execution)
"The origin is down — what do users see?" → Fresh objects are served normally; for misses/expiries the edges serve stale past TTL while the shield retries — availability over strict freshness, so an outage degrades to slightly-old content, not errors. (problem solving)

Each maps to a debrief dimension. Reading this list teaches you the answers; it does not teach you to deliver them while someone interrupts — that only comes from saying them out loud.

How to prepare: a one-week plan

You do not need fifty systems. You need this one cold and the framework automatic, so the next "design X" is just new nouns in the same five steps.

Days 1–2: Learn the five-step framework until it is reflex. Do the CDN end to end on paper — requirements, estimate, API, data model, and the routing/edge/shield/origin boxes.
Days 3–4: Drill routing and freshness: GeoDNS versus anycast and when you'd combine them; TTL, revalidation and stale-while-revalidate; purge versus versioned URLs. Say each trade-off in one sentence.
Days 5–6: Own origin offload — consistent hashing for placement, hot-object replication, request coalescing, the origin shield, and serve-stale on failure. Answer each of the five follow-ups out loud.
Day 7: A full timed 45-minute round, narrating the whole way, with someone (or something) interrupting. This is the rep that counts.

This post is the deep walkthrough behind one row of the broader Top 25 system design interview questions — once the CDN is automatic, the same spine carries the rest of the list.

Frequently asked questions

How do I design a CDN step by step?

Follow the five-step HLD framework. Clarify requirements (serve cached static and media content from near the user, fetch from origin on a miss and cache it, honour TTL/Cache-Control, support purge and versioned-URL invalidation, route to the nearest healthy PoP; non-functionally: low global latency, very high read throughput, a 90%+ cache-hit ratio, origin protection, and HA across PoPs). Estimate to show the cost is the miss, not the hit, and that popularity is skewed toward a few hot objects. Define the small API (GET with conditional revalidation, publish to origin, PURGE, versioned URLs). Draw the design (client → routing layer → nearest edge PoP → regional edge cache / origin shield → origin, plus a control plane and health/load feedback). Then deep-dive request routing (GeoDNS vs anycast), cache population/freshness/invalidation, and origin offload (consistent hashing, coalescing, shield, serve-stale). Finish on the follow-ups about a viral spike and an origin outage.

How does a CDN route a user to the nearest edge?

Two mechanisms, usually combined. GeoDNS: the CDN's authoritative DNS resolves the hostname to the IP of a nearby edge, chosen from the resolver's approximate location plus each PoP's health and load — precise and load-aware, but failover is only as fast as the DNS TTL because resolvers cache the answer. Anycast: every PoP announces the same IP address, and the internet's BGP routing naturally delivers each packet to the topologically nearest PoP — failover is near-instant because withdrawing a route reroutes traffic automatically, but load control is coarse. Real CDNs use anycast for a stable IP and fast failover and layer DNS or application-level steering on top for finer, load-aware placement, with all of it driven by live health signals.

What's the difference between a pull and a push CDN?

A pull CDN caches lazily: the edge fetches an object from the origin on the first cache miss in that region, then serves it from cache until it expires. It is simple, self-healing, and never wastes storage on unrequested objects — the first user in a region pays the miss and everyone after gets a hit. A push CDN has the origin proactively upload content to edges ahead of demand, which avoids a cold first miss for a known launch or a large static library but spends storage and bandwidth on objects that may never be requested. Most CDNs are pull by default and use push selectively for predictable, high-value content.

How does cache invalidation work in a CDN?

Three ways, in order of preference. Versioned (fingerprinted) URLs are cleanest: put a content hash in the path so a new version is a brand-new URL that cannot collide with the cached old one — nothing needs invalidating and the old object can be cached nearly forever. An explicit purge is a control-plane command that drops an object or prefix from every edge immediately; it works but is a global operation with a brief propagation race. A short TTL lets objects refresh on their own via revalidation (ETag/If-None-Match returning 304 Not Modified), optionally with stale-while-revalidate so users never wait. The usual pattern is long TTLs plus versioned URLs for static assets, and short TTLs or purges for genuinely dynamic content.

How does a CDN handle a viral spike without overloading the origin?

With layered origin protection. Within a PoP, objects are placed across edge servers by consistent hashing and hot objects are replicated to more servers so one viral file doesn't overwhelm a single box. The key defence is request coalescing: when thousands of clients miss on the same object at once, the edge issues a single origin fetch and makes everyone wait on that one in-flight request, so a million concurrent misses become one upstream call. The origin shield tier repeats this across PoPs, collapsing misses from many regions into one origin fetch. And if the origin is slow or down, edges serve the stale cached copy past its TTL rather than erroring, so the origin only ever sees a small, smooth trickle of traffic.

How do I practise a system design interview out loud?

Practise it on Zynter

You can read what a cache hit is. The round is won on protecting the origin out loud.

Pick the CDN / Distributed Database round, draw the routing, edge-hierarchy and origin design on the canvas, and defend it out loud to a voice interviewer that keeps asking "a video goes viral in one region — what happens to your origin?" and "you push a new version — how fast does every edge serve it?" — then read the debrief. Zynter.ai is on-demand mock interviews modelled on real company loops, with 150+ rounds across 20 companies including the HLD system design track (Sep 2026).

Practise the CDN round →
Browse all interview tracks

Design an ad click aggregator: the system design interview walkthrough

Gowtham Potureddi — Sun, 18 Oct 2026 21:46:48 +0000

Design an ad click aggregator: the system design interview walkthrough

The request to design an ad click aggregator sounds like one line — count the clicks on each ad — and that one line hides the whole interview. Picture it for one advertiser and a COUNT(*) settles it; picture it at ad-network scale, where tens of thousands of clicks land every second and an advertiser wants clicks-per-minute for their campaign updated almost live, and you quickly see you can neither scan a billion raw rows per query nor keep a perfect running total in one place. This is one of the most revealing real-time analytics prompts — the Google-Ads-style question — because it is the textbook scaling-writes problem: the firehose of writes dwarfs the trickle of reads, so the entire design bends around ingesting a torrent without losing a click and turning it into numbers you can actually query.

The round turns on one structural insight. "Count the clicks" is not a counter — it is a streaming aggregation pipeline. You cannot afford to store every raw click and re-scan it per query, so you buffer the firehose in a log, pre-aggregate it in a stream processor over time windows, and serve cheap reads from pre-computed rollups (clicks per ad per minute) in an analytics store. And there is a second twist that separates a good answer from a great one: those counts are billing numbers, so "fast but roughly right" is not enough — you add a slower, authoritative path that re-computes the counts from the raw events and reconciles them, which is exactly the lambda architecture (a fast speed layer plus a correct batch layer). Get that reframe — ingest to a log, aggregate the stream, serve rollups, reconcile for accuracy — and the rest of the system design interview is deciding how not to lose a click, how to bucket clicks by the minute they actually happened, and how to keep the totals exact enough to charge money against. This walkthrough follows the path a strong candidate draws on the whiteboard — requirements, estimate, API and data model, high-level design, then the deep dives — naming the follow-up the interviewer uses at each step to tell a memorised answer from real understanding.

How the ad click aggregator round is actually run

An ad click aggregator round runs about 45 minutes on a shared canvas — you draw the boxes and arrows while you talk, and the interviewer interrupts. It is a favourite because the one-line problem opens onto deep water fast: the moment you draw "count clicks," the question becomes what happens to a single click at scale and how is a per-minute number ready to query, and every answer after that compounds from those two. The clock is a touch tighter than the hour-long rounds, so you have to spend your minutes on ingestion, aggregation and accuracy, not on the ad-serving side.

The interviewer rarely lets "count the clicks" stand. "You're taking in tens of thousands of clicks a second, and an advertiser wants clicks-per-minute for their ad on a dashboard — you're obviously not going to run COUNT(*) over a billion rows per query, so what actually happens to a single click from the moment it lands?" That question — the life of a click in a high-write pipeline — is the one a copied answer can never rehearse, and the one this round is really testing.

The five-step framework for any HLD round

Every high-level design answer fits the same spine. Say it out loud at the start so the interviewer knows you have a plan, then walk it:

Clarify requirements — functional and non-functional, and what you are explicitly not building.
Estimate — clicks per second versus advertiser query rate, to justify every later choice.
High-level design — the boxes and arrows: ingest to a log, aggregate in a stream processor, serve rollups, and a batch path to reconcile.
Deep dive — the two or three decisions that actually decide this system.
Follow-ups — bottlenecks, failure modes, and what you would change at ten times the scale.

What the debrief measures

The score is not "right or wrong design." A good HLD debrief reads on four dimensions, and every move below maps to one: problem solving (did you reframe it as scaling writes — buffer, pre-aggregate, serve rollups — and add a batch layer for accuracy), communication (did you say why a log buffers the firehose and why you bucket by event time, in a single sentence), technical execution (a partitioned, retained log; a stream processor doing event-time windowed aggregation with watermarks and exactly-once; idempotent writes and a reconciling batch job), and time management (did you spend your 45 minutes on ingestion, aggregation and accuracy, not on ad targeting). Reading a walkthrough teaches the design; it does not teach you to deliver it on the clock while someone pushes back.

Step 1 — Requirements: what an ad click aggregator must do

Spend the first few minutes here. Jumping to boxes before you have scoped the problem is the fastest way to design the wrong system.

Type	Requirement
Functional	Record every ad click; let advertisers query aggregated metrics — clicks per ad over time, e.g. at per-minute granularity; power near-real-time dashboards; the counts are accurate enough to bill on.
Functional (optional)	Extra dimensions (geo, device, campaign), click-through-rate, fraud / invalid-click filtering, longer rollup tiers (hourly, daily) — call these out, then scope most of them for later.
Non-functional	Very high write throughput with no data loss; low-latency reads over aggregates; accuracy (eventually exact, because it drives billing); horizontally scalable; resilient to spikes and processor failures.

The sentence that earns points: "This is a scaling-writes problem — clicks hugely outnumber queries — so I buffer the firehose in a log, pre-aggregate it in a stream processor into per-minute rollups I can query cheaply, and because these counts are billed, I add a batch layer to re-compute from raw events and reconcile." Say that and you have framed the entire design before drawing a box.

Step 2 — Capacity estimation (back of the envelope)

Estimation here is about proving one thing: writes overwhelmingly dominate reads, so the system is built around ingesting and pre-aggregating, not around querying raw data.

Quantity	Assumption	Result
Clicks	tens of thousands per second at peak, bursty	a firehose of writes — the scaling axis; it must be buffered and never dropped
Advertiser queries	a comparatively tiny number of dashboard reads	reads are trivial if they hit pre-aggregated rollups, not raw events
Raw event volume	billions of click rows accumulating	too large to scan per query — archive raw to a data lake, serve from rollups
Aggregation granularity	per-minute buckets per ad	a bounded number of small rollup rows — cheap to store and query

Two conclusions fall out, and you should say both out loud. First, writes are the whole problem — the click rate dwarfs the query rate, so the architecture (a log to absorb the firehose, a stream processor to pre-aggregate, partitioning by ad id) exists to handle write throughput without losing data. Second, reads are easy once you pre-aggregate — an advertiser querying clicks-per-minute reads a handful of small rollup rows, never a billion raw clicks, so the read path is almost an afterthought if the write path did its job. You have now pointed the interview at the real deep dives — ingestion, aggregation, and accuracy — before anyone asked.

Step 3 — API and data model

The API is deliberately small: clicks go in, aggregated metrics come out.

Operation	Shape
`record_click(ad_id, user_id, ts, metadata)`	fired when an ad is clicked; appended to the log as a raw event — fast and fire-and-forget.
`get_metrics(ad_id, time_range, granularity)`	returns aggregated clicks over the range (e.g. per minute) from the rollup store.

The data model is thin, and split by purpose: raw events are the durable truth; rollups are the query surface.

Entity	Notes
`click_event`	`(ad_id, user_id, event_ts, metadata)` — the raw click, held in the log (short-term) and archived to a data lake (long-term) for reprocessing.
`aggregate_rollup`	`(ad_id, window_start, count)` — pre-computed per-ad, per-window counts in an OLAP / time-series store; this is what advertiser queries read.

Step 4 — High-level design: ingest, aggregate, query (and reconcile)

Now the boxes. A click's whole life is a pipeline from a lightweight ingest service, through a log, into a stream processor, out to rollups — with a second, slower path for correctness:

Click-processing service: receives record_click and does almost nothing but append the event to a log — stateless and fast, so it can absorb the firehose.
Log (Kafka / Kinesis): the backbone. It buffers spikes, decouples ingest from the slower aggregator, is partitioned by ad id, and is replicated and retained (e.g. 7 days) so nothing is lost and a crashed consumer can replay.
Stream processor (Flink / Spark Streaming): consumes the log and aggregates clicks per ad per time window, then flushes rollups to the analytics store. This is the speed layer.
OLAP / time-series store: holds the small per-ad, per-minute rollups; a query service serves advertiser dashboards cheap reads over them.
Data lake + batch job (the batch layer): raw events are also archived to a data lake (S3), where a periodic batch job re-aggregates them from scratch and reconciles the rollups — the authoritative, billing-grade numbers.

Say explicitly that this is a write-side aggregation pipeline with two layers: a fast stream path for low-latency approximate counts, and a slower batch path for exact, billable counts, both feeding the same rollups. Naming that — log, stream processor, rollups, and a reconciling batch job — is a signal the interviewer is listening for.

Deep dive: ingesting the click firehose without losing data

This is the first decision that actually decides the round. The follow-up is about the spike: a viral moment triples the click rate and your aggregator falls behind — do you drop clicks?

The answer is no, and the reason you do not have to is the log. The click-processing service does the minimum — append each click to a distributed log like Kafka or Kinesis — and the log does the heavy lifting that makes the firehose survivable:

Log property	What it buys
Buffering	the log absorbs bursts; if the aggregator falls behind, clicks queue durably instead of being dropped — the processor catches up when the spike passes.
Decoupling	ingest and aggregation scale independently; a slow consumer never backs pressure onto the click-processing service.
Partitioning by ad id	clicks for an ad land on the same partition, so aggregation parallelises across partitions and ordering per ad is preserved.
Replication + retention	the log is replicated across brokers/zones (no loss if a node dies) and retained for days, so a crashed consumer replays from its last offset.

The reason a spike cannot force you to drop clicks is that the log is durable storage, not a transient pipe — it holds the events until the processor has consumed them, and keeps holding them for the retention window even after. If the stream processor crashes, it comes back and resumes from its committed offset, re-reading anything it missed. Saying plainly that the log is the buffer and the safety net — not just a message bus — is the sentence that separates a real answer from a hand-wave.

"A traffic spike triples the click rate and your aggregator falls behind — do you drop clicks?" No — the click-processing service only appends each click to a durable, replicated log like Kafka, which buffers the spike. The aggregator consumes at its own pace and simply catches up once the burst passes; because the log is retained for days, even a crashed processor replays from its last offset and loses nothing. The log is the buffer and the safety net, so backpressure never reaches ingestion.

System Design
HLD · Media & analytics · 45 min
Design an ad click aggregator out loud, with follow-ups

Practise on Zynter →

Deep dive: aggregating the stream over time windows

Ingestion keeps every click; this turns the stream into numbers. The follow-up is the one that trips people: a click that happened at 11:59 doesn't arrive until 12:01 — which minute does it count in, and how do you even know the 11:59 window is finished?

The job is to aggregate clicks per ad, per time window — tumbling one-minute buckets — and the subtlety is which time you bucket by. A stream processor like Flink (or Spark Streaming) consumes the log and does this properly:

Event time, not arrival time: bucket each click by when the click actually happened (event_ts), not when the processor received it. A click from 11:59 that arrives at 12:01 still counts in the 11:59 window — otherwise network lag would smear your numbers across the wrong minutes.
Watermarks close windows: a watermark tracks how far event time has progressed, so the processor knows when it is safe to say "the 11:59 window is done" and flush it — while still tolerating a bounded amount of late, out-of-order arrival.
Exactly-once, fault-tolerant state: the processor keeps running per-window counts as managed state with exactly-once guarantees and recovers that state after a failure — which is why you reach for a real stream processor rather than a hand-rolled consumer keeping a count in memory.
Flush rollups to the store: when a window closes, its per-ad counts are written to the OLAP / time-series store as rollups. You can shrink the window or flush more often to trade latency against completeness — tighter windows mean fresher dashboards.
Hot ads: a viral ad can hotspot one partition; split the hot key into sub-keys (adA#0 … adA#n) for a first aggregation pass and merge in a second — two-stage aggregation — so no single task is a bottleneck.

The point to state plainly: event time plus watermarks is what makes the counts correct under the messiness of a real network, where clicks arrive late and out of order. A naive per-minute consumer that counts by arrival time is easy to describe and quietly wrong; saying why you bucket by event time is the signal of someone who has thought about streaming, not just drawn it.

"A click from 11:59 arrives at 12:01 — which minute does it count in, and how do you know the 11:59 window is done?" It counts in 11:59, because the processor buckets by the click's event time, not its arrival time. A watermark tracks how far event time has advanced, so once it passes 11:59 (allowing a small grace for late arrivals) the processor knows that window is complete, flushes its per-ad counts to the rollup store, and still slots a slightly-late click into the right bucket. Event time plus watermarks is what keeps the minute-by-minute numbers honest.

System Design
HLD · Media & analytics · 45 min
Defend event-time windowed aggregation out loud

Practise on Zynter →

Deep dive: keeping the counts accurate — idempotency and reconciliation

Windowing gives you fast numbers; this makes them numbers you can put on an invoice. The follow-up is the one with money attached: your stream double-counted a window after a crash, and this number is a bill — how do you make it right?

Two different accuracy problems need two different fixes, and naming both is what separates a senior answer:

Idempotency / exactly-once writes (stop double-counting): the classic failure is the processor flushing a window's rollup to the store but crashing before committing its stream offset — on restart it reprocesses the same window and over-counts. Fix it by making the flush idempotent: commit the aggregated result and the stream offset atomically (one transaction, or an upsert keyed by (ad_id, window) so re-applying is a no-op). Now a replay after a crash cannot inflate the count.
Batch reconciliation (correct the drift): even with idempotent writes, transient processing errors, a bad deploy, or extreme out-of-order events leave the speed layer slightly off. So also archive the raw events to a data lake (S3) and run a periodic batch job (e.g. a daily Spark job) that re-aggregates from the raw events and reconciles — correcting the real-time rollups to the exact counts. The batch result is the billing-grade source of truth.

This pairing — a fast speed layer (the stream) for low-latency dashboards plus a slower batch layer (re-aggregation from raw) for correctness — is the lambda architecture. The dashboard shows near-real-time approximate counts within seconds; the batch job guarantees that what you actually bill is exact. While you are here, name fraud / invalid-click filtering (bots, repeated clicks from one user) as a real concern, even if you scope the detail out — billable clicks have to be valid clicks.

"Your stream double-counted a window after a crash and this number is a bill — how do you make it right?" Two ways working together. First, I make the flush idempotent — the window's count and the stream offset commit atomically, so a replay after a crash can't over-count. Second, I keep the raw events in a data lake and run a periodic batch job that re-aggregates them and reconciles the rollups, so the billed number is recomputed from source and exact. Fast approximate counts from the speed layer, authoritative counts from the batch layer — the lambda architecture.

The follow-ups that decide the ad click aggregator round

Scan the probes from each deep dive and they rhyme. Master these five and you are ready for a version of the question that is not drawn exactly like this one.

"A spike triples the click rate — do you drop clicks?" → No: the click-processing service appends to a durable, replicated, retained log that buffers the burst; the aggregator catches up at its own pace and a crashed processor replays from its offset, so nothing is lost. (problem solving)
"How do you serve clicks-per-minute without scanning raw events?" → You pre-aggregate on the write side: a stream processor rolls clicks up per ad per minute into an OLAP store, and advertiser queries read small rollup rows, never the billions of raw clicks. (technical execution)
"A click arrives two minutes late — which window does it count in?" → The one matching its event time, not arrival time; a watermark tells the processor when a window is safe to close while still admitting bounded late events, so the minute-by-minute counts stay correct. (technical execution)
"The stream double-counted after a crash — how do you fix a billed number?" → Make the flush idempotent (commit count and offset atomically so replays don't over-count), and reconcile with a periodic batch re-aggregation from raw events in a data lake — the authoritative total. (communication)
"Why keep both a stream and a batch path?" → The lambda architecture: the speed layer gives near-real-time approximate dashboards, the batch layer recomputes exact, billing-grade counts from raw events — fast and correct, instead of choosing one. (problem solving)

Each maps to a debrief dimension. Reading this list teaches you the answers; it does not teach you to deliver them while someone interrupts — that only comes from saying them out loud.

How to prepare: a one-week plan

You do not need fifty systems. You need this one cold and the framework automatic, so the next "design X" is just new nouns in the same five steps.

Days 1–2: Learn the five-step framework until it is reflex. Do the ad click aggregator end to end on paper — requirements, estimate, API, data model, and the ingest/aggregate/query/reconcile boxes.
Days 3–4: Drill ingestion and aggregation: why a log buffers the firehose and enables replay, and how a stream processor windows clicks by event time with watermarks. Say each tradeoff in one sentence.
Days 5–6: Own accuracy — idempotent flushes to stop double-counting, and the batch reconciliation that makes counts billable (the lambda architecture). Answer each of the five follow-ups out loud.
Day 7: A full timed 45-minute round, narrating the whole way, with someone (or something) interrupting. This is the rep that counts.

This post is the deep walkthrough behind one row of the broader Top 25 system design interview questions — once the ad click aggregator is automatic, the same spine carries the rest of the list.

Frequently asked questions

How do I design an ad click aggregator step by step?

Follow the five-step HLD framework. Clarify requirements (record every click; let advertisers query aggregated clicks over time, e.g. per minute; near-real-time dashboards; counts accurate enough to bill); estimate to show that writes (tens of thousands of clicks per second) massively dominate reads, so it is a scaling-writes problem; define the small API (record_click appended to a log, get_metrics reading rollups) with a raw-event-vs-rollup data model; draw the design (click-processing service → a partitioned, retained log like Kafka → a stream processor aggregating per ad per window → an OLAP/time-series store of rollups → a query service, plus raw events to a data lake and a periodic batch job to reconcile); then deep-dive ingestion without data loss, windowed aggregation, and accuracy. Finish on the follow-ups about spikes and double-counting.

How do you ingest a high-volume click stream without losing data?

By putting a durable distributed log between ingestion and aggregation. The click-processing service does almost nothing but append each click to a log like Kafka or Kinesis, which buffers spikes, decouples the fast ingest path from the slower aggregator, partitions clicks by ad id for parallelism, and replicates the data across brokers or availability zones so a node failure loses nothing. With a retention window of several days, even a crashed stream processor can replay from its last committed offset and re-read anything it missed. Because the log is durable storage rather than a transient pipe, a traffic spike simply queues up and the aggregator catches up afterward — backpressure never forces you to drop clicks.

How does stream processing aggregate clicks over time windows?

A stream processor such as Flink or Spark Streaming consumes the log and maintains running counts per ad per time window — typically tumbling one-minute buckets — then flushes those rollups to an analytics store. The key subtlety is that it buckets clicks by event time (when the click happened) rather than processing time (when it arrived), so a click delayed by the network still lands in the correct minute. Watermarks track how far event time has advanced so the processor knows when a window is complete and safe to flush while still admitting bounded late events, and its windowed state is kept with exactly-once guarantees and recovered after failures. That is why a purpose-built stream processor is preferred over a hand-rolled consumer counting in memory.

What is the lambda architecture and why reconcile the counts?

The lambda architecture pairs a fast speed layer with a correct batch layer. The speed layer is the stream processor, which produces near-real-time but approximate counts for dashboards. The batch layer archives the raw click events to a data lake and periodically — say daily with a Spark job — re-aggregates them from scratch and reconciles the rollups, producing exact, authoritative numbers. You reconcile because transient processing errors, bad deploys, and extreme out-of-order events can leave the real-time counts slightly off, and in an ad system those counts are billed. Combining both layers lets the system be fast for monitoring and exact for billing, instead of forcing a choice between latency and correctness.

How do you keep ad click counts accurate enough to bill on?

With idempotency on the write side and reconciliation on the batch side. Idempotency prevents double-counting: if the stream processor flushes a window but crashes before committing its offset, a naive restart would reprocess and over-count, so you commit the aggregated result and the stream offset atomically (or upsert keyed by ad and window) to make reprocessing a no-op. Reconciliation corrects residual drift: a periodic batch job re-aggregates from the raw events stored in a data lake and overwrites the rollups with exact totals, which become the billing source of truth. You also filter fraudulent and invalid clicks, since only valid clicks should be billed. Together these make the numbers trustworthy enough to charge against.

How do I practise a system design interview out loud?

Practise it on Zynter

You can read why the log buffers the firehose. The round is won on saying it under follow-ups.

Pick the Ad Click Aggregator round, draw the ingest-aggregate-query design on the canvas, and defend it out loud to a voice interviewer that keeps asking "a spike triples the clicks — do you drop any?" and "this count is a bill — how do you make it exact?" — then read the debrief. Zynter.ai is on-demand mock interviews modelled on real company loops, with 150+ rounds across 20 companies including the HLD system design track (Sep 2026).

Practise the Ad Click Aggregator round →
Browse all interview tracks

Design Pastebin: the beginner-friendly system design interview walkthrough

Gowtham Potureddi — Sun, 18 Oct 2026 21:43:43 +0000

Design Pastebin: the beginner-friendly system design interview walkthrough

The request to design Pastebin sounds like one line — paste some text, get a short link, share it — and that one line is exactly why it is the best first system design interview you can practise. It looks almost identical to a URL shortener, so the moves are foundational, yet it hides one real twist that teaches the core of storage design: a shortener remembers a tiny web address, but Pastebin stores and serves arbitrary-size content that has to expire. That single difference is what turns a toy into a proper HLD, and learning to spot it is the whole lesson.

The round turns on one structural insight. "Paste text, get a link" looks like a shortener until you ask where a megabyte of pasted logs actually goes — and the answer is not in the little database that maps your link to it. The body of a paste belongs in blob (object) storage, kept apart from the small, queryable metadata that records the key, where the body lives, and when it expires. From there everything follows: the system is overwhelmingly read-heavy (a paste is written once and read many times), so it is cache-first behind a CDN; and because every paste carries a TTL, old content is swept away and the storage footprint stays small. Get that reframe — a URL shortener plus arbitrary-size content plus expiry — and the rest of the Pastebin system design is three clean decisions: how to mint a short unique key, where the body lives and how reads scale, and how pastes expire. This walkthrough follows the path a strong candidate draws on the whiteboard — requirements, estimate, API and data model, high-level design, then the deep dives — naming the follow-up the interviewer uses at each step to tell a memorised answer from real understanding.

How the Pastebin round is actually run

A Pastebin round runs about 45 minutes on a shared canvas — you draw the boxes and arrows while you talk, and the interviewer interrupts. It is a favourite first system because the requirements are small enough to hold in your head, so the round is really a test of judgement: can you keep a simple product simple while still making the right calls on storage, read scaling and cleanup, instead of either under-thinking it ("just a database") or over-building it with machinery it does not need. The clock is a touch tighter than the hour-long rounds, which suits a focused problem — spend your minutes on the key, the storage split, and expiry.

The interviewer rarely lets "it's basically a URL shortener" stand. "Fine — so what's actually different from a shortener, and when someone pastes a megabyte of logs, where does that text go and why not just put it in the database?" That question — content storage, not link mapping — is the one a copied answer can never rehearse, and the one this round is really testing.

The five-step framework for any HLD round

Every high-level design answer fits the same spine. Say it out loud at the start so the interviewer knows you have a plan, then walk it:

Clarify requirements — functional and non-functional, and what you are explicitly not building.
Estimate — reads versus writes and the size of a paste, to justify every later choice.
High-level design — the boxes and arrows: the write path that mints a key and stores the body, and the read-heavy path that serves it.
Deep dive — the two or three decisions that actually decide this system.
Follow-ups — bottlenecks, failure modes, and what you would change at ten times the scale.

What the debrief measures

The score is not "right or wrong design." A good HLD debrief reads on four dimensions, and every move below maps to one: problem solving (did you see past "URL shortener" to arbitrary-size, read-heavy, expiring content), communication (did you say why the body goes to blob storage and not the metadata DB, in a single sentence), technical execution (a collision-free key, metadata separate from the blob, cache-first reads behind a CDN, and a TTL with lazy delete plus cleanup), and time management (did you keep a simple product simple and spend your 45 minutes on storage and expiry, not on re-deriving base62). Reading a walkthrough teaches the design; it does not teach you to deliver it on the clock while someone pushes back.

Step 1 — Requirements: what Pastebin must do

Spend the first few minutes here. Jumping to boxes before you have scoped the problem is the fastest way to design the wrong system.

Type	Requirement
Functional	A user pastes text and gets back a short, unique link; anyone opening that link reads the content; the user can set an expiry; pastes can be public, unlisted, or private.
Functional (optional)	Syntax highlighting, custom aliases, edit-after-create, view analytics — call these out, then scope most of them for later.
Non-functional	Read-heavy (far more reads than writes); highly available; content durable until it expires; low-latency reads; cheap storage that does not grow without bound.

The sentence that earns points: "It's a URL shortener plus two things — the body is arbitrary-size content, so it lives in blob storage separate from the metadata, and every paste expires, so the footprint stays small; and it's read-heavy, so it's cache-first." Say that and you have framed the entire design before drawing a box.

Step 2 — Capacity estimation (back of the envelope)

Estimation here is about proving three things: reads dominate writes, a paste can be large, and expiry keeps storage bounded.

Quantity	Assumption	Result
Writes	modest — some pastes per second at peak	ordinary write volume; the write path is not the scaling problem
Reads	each paste read many times (shared links)	reads dominate by orders of magnitude — the design must be cache-first
Paste size	a few lines up to several megabytes	too big to sit inline in the metadata DB — the body belongs in blob / object storage
Active footprint	daily writes × an expiry window of days	bounded — expiry caps total storage at roughly a few days of pastes, not forever

Two conclusions fall out, and you should say both out loud. First, reads are the axis that matters — writes are cheap and occasional, but the same link can be opened thousands of times, so the design leans on a cache and a CDN and treats storage as read-mostly. Second, expiry is what keeps it cheap — because every paste has a TTL, you are never storing the whole history of the internet, just a rolling window, which also shapes how you clean up. You have now pointed the interview at the real deep dives — the key, the storage split, and expiry — before anyone asked.

Step 3 — API and data model

The API is deliberately small: create a paste, read it, maybe delete it.

Operation	Shape
`create_paste(content, expiry, visibility)`	stores the body, writes metadata, and returns the short `key` / URL.
`get_paste(key)`	returns the paste content (or a 404 if missing or expired).
`delete_paste(key)`	removes a paste before its expiry (owner action).

The data model is thin, and the whole trick is in the split: small metadata in a datastore, the large body in a blob store.

Entity	Notes
`paste_metadata`	`key`, `blob_location`, `created_at`, `expires_at`, `size`, `visibility` — small, queryable, keyed by the short key; the index into everything.
`paste_body`	the raw pasted text, stored in blob / object storage at `blob_location` — large and opaque, never inline in the metadata DB.

Step 4 — High-level design: the write path and the read path

Now the boxes. Clients hit stateless app servers behind a load balancer, and the system splits cleanly into a modest write path and a read-heavy read path:

Write path: an app server asks a key-generation service for a short unique key, stores the body in the blob / object store, writes the metadata (key → blob location, created, expires_at, size, visibility) to the datastore, and returns the key as a URL.
Read path: GET /{key} looks up the metadata, then fetches the body cache-first — from an in-memory cache or CDN on a hit, falling through to the blob store only on a miss — and serves it.
Cache + CDN: because a paste never changes after creation, it caches beautifully; hot pastes live in cache and at CDN edges, so the blob store sees only misses.
Stateless servers: the app tier holds no session state, so it scales horizontally behind the load balancer.
Expiry sweeper: a background job (or native store TTL) removes pastes whose expires_at has passed, keeping storage bounded.

Say explicitly that the small metadata and the large blob are stored separately, and that reads are cache-first because a paste is immutable. Naming that split — key-gen plus metadata plus blob, with a cache in front — is a signal the interviewer is listening for.

Deep dive: generating the short, unique key

This is the first decision, and it is the half Pastebin shares with a URL shortener — so name that kinship, get it right, and keep it tight rather than re-deriving it for ten minutes. The follow-up is about collisions: how do two app servers both hand out keys without ever clashing?

You need a key that is short, URL-safe, and collision-free. The common approaches, as tradeoffs:

Approach	What it optimises / costs
Counter + base62	a key-generation service (or a distributed counter) hands each app server a range of numbers; encode each in base62 (`A–Z a–z 0–9`). Guaranteed unique with no collision check, and ~7 chars covers a huge keyspace — the clean default.
Random + collision check	generate N random URL-safe characters and check the datastore for a clash, retrying on the rare hit. Simple and unguessable, but needs a read before every write.
Hash + truncate	hash the content (plus a salt/time) and take a prefix. No coordination, but collisions must still be handled and identical content can map to the same hash.

Reach for counter + base62: pre-allocating ranges to each writer means two servers never pick the same key and neither needs to check for collisions, which keeps the write path fast. Base62 keeps the key short and safe to drop straight into a URL. If the requirement is that unlisted pastes be unguessable, lean toward a random key (or add random bits) so the next key can't be inferred from the last. Saying out loud that this is the same core problem as a URL shortener — and that the interesting part of Pastebin is the storage, not the key — shows you know where to spend your minutes.

"How do two app servers both hand out keys without ever colliding?" I don't let them pick freely. A key-generation service hands each server a pre-allocated range of numbers, and each is encoded in base62, so two servers draw from disjoint ranges and can never produce the same key — no collision check needed on the write path. If I also need unlisted pastes to be unguessable, I add random bits so the next key can't be inferred from the last.

System Design
HLD · Storage & files · 45 min
Design Pastebin out loud, with follow-ups

Practise on Zynter →

Deep dive: storing the paste — metadata vs blob, and read-heavy serving

This is the decision that makes Pastebin more than a shortener, and the one the round is really about. The follow-up is blunt: someone pastes a megabyte of logs — where does that go, and why not in the database?

The answer is that the big body does not belong in your metadata database. Row stores are built for small, structured, queryable records — not for multi-megabyte opaque blobs, which bloat the rows, slow every query, and waste the database's expensive strengths on bytes it never needs to index. So you split storage by shape:

Metadata in a datastore: key → blob_location, created_at, expires_at, size, visibility — small, indexed by the short key, cheap to query. This is what the read path hits first.
Body in blob / object storage: the raw text sits in an object store (S3-style) at blob_location, which is built for large, cheap, durable, write-once objects. The metadata points to it.
Read is metadata-then-blob, cache-first: GET /{key} looks up the metadata, then fetches the body — served from an in-memory cache or a CDN on a hit, and from the blob store only on a miss.
Immutable means cacheable: a paste never changes after it is written, so it can be cached aggressively and sit at CDN edges indefinitely (until it expires) — exactly what makes a read-heavy system cheap.

The point to state plainly: separating the small, queryable metadata from the large, opaque blob is the Pastebin-specific move, and it is what lets reads scale through a cache and CDN while the database stays lean. A URL shortener never needs this because its "body" is a single short string; Pastebin does, because its body is content.

"Someone pastes a megabyte of logs — where does that go, and why not in the database?" Not in the metadata database — a row store is for small, queryable records, and a multi-megabyte blob would bloat the rows and slow every query. The body goes to blob / object storage, which is built for large, cheap, durable objects, and the metadata just holds a pointer to it. The read path looks up metadata by key, then serves the body cache-first from a CDN — and because a paste never changes, it caches beautifully.

System Design
HLD · Storage & files · 45 min
Defend the metadata-vs-blob storage split out loud

Practise on Zynter →

Deep dive: expiration, TTL and keeping it clean

Storage decides where a paste lives; this decides when it leaves — and it is the piece that keeps the whole system cheap. The follow-up is about the mechanics: a paste is set to expire in an hour — what actually deletes it, and what does a reader see after?

Every paste carries an expires_at, set by the user or a default. You enforce it with two mechanisms working together, because either alone has a gap:

Lazy deletion on read: when a get_paste arrives, check expires_at; if it has passed, treat the paste as gone — return a 404 and don't serve stale content. This guarantees correctness instantly, even before anything is physically removed.
Background cleanup (or native TTL): a sweeper job periodically deletes expired pastes from the blob store and metadata datastore — or you set a native TTL on the records so the store evicts them for you. This reclaims space so storage stays bounded, which lazy deletion alone would not do (an un-read expired paste would linger forever).
Why both: lazy deletion keeps reads correct the instant a paste expires; the cleanup job keeps storage bounded over time. Together they mean a reader never sees expired content and you never pay to store it.

While you are here, name the cheap, mature guards the interviewer wants to hear: pastes can be public, unlisted, or private, and a hard-to-guess key makes an unlisted paste effectively unreachable without the link; and the write path is rate-limited so the service can't be flooded with spam pastes. These are the "sound choices" that show judgement without over-building.

"A paste is set to expire in an hour — what actually deletes it, and what does a reader see after?" Two things working together. On read, I check expires_at and return a 404 the moment it has passed, so no one ever sees expired content — that's lazy deletion. Separately, a background cleanup job (or a native TTL on the store) physically removes expired pastes from the blob and metadata stores so the footprint stays bounded. Lazy deletion keeps reads correct instantly; the sweeper keeps storage cheap over time.

The follow-ups that decide the Pastebin round

Scan the probes from each deep dive and they rhyme. Master these five and you are ready for a version of the question that is not drawn exactly like this one.

"How is this different from a URL shortener?" → Same key-generation half, but Pastebin stores and serves arbitrary-size content that expires: the body goes to blob storage separate from the metadata, reads are cache-first, and everything has a TTL. (problem solving)
"How do you generate a unique key without collisions?" → A key-generation service hands each writer a pre-allocated range encoded in base62, so two servers never collide and no collision check is needed; add random bits if unlisted pastes must be unguessable. (technical execution)
"Where does the paste body live, and why not the database?" → In blob / object storage, which is built for large, cheap, durable objects; the metadata database only holds a small pointer plus timestamps, so queries stay fast and the big content caches well. (communication)
"It's read-heavy — how do you scale reads?" → Cache-first: an in-memory cache and a CDN serve hot pastes, and since a paste is immutable it caches aggressively; the blob store only sees misses, and app servers are stateless behind a load balancer. (technical execution)
"How do pastes expire without storage growing forever?" → Lazy deletion returns a 404 on read the instant expires_at passes, and a background cleanup job or native store TTL physically removes expired pastes, so reads stay correct and the footprint stays bounded. (problem solving)

Each maps to a debrief dimension. Reading this list teaches you the answers; it does not teach you to deliver them while someone interrupts — that only comes from saying them out loud.

How to prepare: a one-week plan

You do not need fifty systems. You need this one cold and the framework automatic, so the next "design X" is just new nouns in the same five steps.

Days 1–2: Learn the five-step framework until it is reflex. Do Pastebin end to end on paper — requirements, estimate, API, data model, and the write-path/read-path boxes.
Days 3–4: Drill the key and the storage split: counter + base62 keys, and why the body goes to blob storage while metadata stays in the datastore, served cache-first. Say each tradeoff in one sentence.
Days 5–6: Own expiry and read scaling — lazy deletion plus a cleanup job, the cache and CDN, and the public/unlisted/private + rate-limiting guards. Answer each of the five follow-ups out loud.
Day 7: A full timed 45-minute round, narrating the whole way, with someone (or something) interrupting. This is the rep that counts.

This post is the deep walkthrough behind one row of the broader Top 25 system design interview questions — once Pastebin is automatic, the same spine carries the rest of the list.

Frequently asked questions

How do I design Pastebin step by step?

Follow the five-step HLD framework. Clarify requirements (paste text and get a short unique link; open the link to read the content; set an expiry; public / unlisted / private); estimate to show it is read-heavy, that a paste can be large, and that expiry keeps storage bounded; define the small API (create_paste, get_paste, delete_paste) with the key split — small metadata in a datastore, the large body in blob storage; draw the design (stateless app servers behind a load balancer; a write path that mints a key, stores the body in the blob store and the metadata in the datastore; a read-heavy path that looks up metadata and serves the body cache-first from a cache or CDN; an expiry sweeper); then deep-dive the key generation, the metadata-vs-blob storage, and expiration. Finish on the follow-ups about collisions and where the body lives.

How does Pastebin generate a unique key for each paste?

With a short, URL-safe, collision-free key — most cleanly a counter plus base62. A key-generation service (or distributed counter) hands each app server a pre-allocated range of numbers, and each number is encoded in base62 (A–Z, a–z, 0–9), so two servers draw from disjoint ranges and can never produce the same key, with no collision check needed on the write path; roughly seven base62 characters already cover a huge keyspace. Alternatives are generating a random URL-safe string and checking the datastore for a clash, or hashing the content and truncating. If unlisted pastes must be unguessable, use random keys (or add random bits) so the next key can't be inferred from the last. It is the same key problem as a URL shortener.

Where is the paste content stored — the database or object storage?

The large paste body goes in blob / object storage, not the metadata database. A relational or row store is built for small, structured, queryable records, and a multi-megabyte blob would bloat the rows and slow every query. So the body lives in an object store (S3-style) that is built for large, cheap, durable, write-once objects, and the metadata database holds only a small record — the key, the blob's location, timestamps, size and visibility — keyed by the short key. The read path looks up the metadata, then fetches the body cache-first. Separating the small, queryable metadata from the large, opaque blob is the move that distinguishes Pastebin from a URL shortener.

How do you scale Pastebin for read-heavy traffic?

By making reads cache-first, which works because a paste is immutable once written. Hot pastes are served from an in-memory cache and from a CDN at the edge, so the same shared link can be opened thousands of times without touching the blob store, which only sees cache misses. App servers are stateless behind a load balancer so they scale horizontally, and the metadata datastore and blob store are read-replicated. Writes are modest and do not need the same machinery. Because content never changes after creation, aggressive caching is safe and cheap — exactly what a read-heavy, write-once workload wants.

How does paste expiration and TTL cleanup work?

Each paste stores an expires_at timestamp, and you enforce it two ways at once. Lazy deletion handles correctness: when a read arrives, you check expires_at and return a 404 the moment it has passed, so a reader never sees expired content even before anything is physically removed. A background cleanup job — or a native TTL on the blob store and datastore — handles space: it periodically deletes expired pastes so storage stays bounded, which lazy deletion alone would not do because an un-read expired paste would linger forever. Together they keep reads correct instantly and storage cheap over time, so the active footprint is only a rolling window of pastes rather than the whole history.

How do I practise a system design interview out loud?

Practise it on Zynter

You can read why the body goes to blob storage. The round is won on saying it under follow-ups.

Pick the Pastebin round, draw the write-path and read-path design on the canvas, and defend it out loud to a voice interviewer that keeps asking "how is this different from a URL shortener?" and "where does a megabyte of pasted text go?" — then read the debrief. Zynter.ai is on-demand mock interviews modelled on real company loops, with 150+ rounds across 20 companies including the HLD system design track (Sep 2026).

Practise the Pastebin round →
Browse all interview tracks