The four letters​

• Atomicity — a transaction's operations happen as one indivisible unit: all of them succeed, or none of them do. A transfer that debits one account and credits another either does both or neither — never just one.
• Consistency — a transaction moves the database from one valid state to another, respecting its own defined rules (constraints, foreign keys). Worth noting: this is a narrower guarantee than the "C" in the CAP theorem — related idea, different scope, and conflating the two is a common mistake.
• Isolation — concurrent transactions don't see each other's uncommitted, in-progress changes. Without isolation, one transaction could read another's half-finished work.
• Durability — once a transaction commits, it survives a crash. A confirmed write isn't going to vanish because the server lost power a second later.

Isolation levels: how much concurrency correctness costs​

Isolation isn't all-or-nothing — databases offer a spectrum of isolation levels, each allowing a different set of anomalies in exchange for better concurrency performance:

The pattern across the table: each stricter level closes off one more category of anomaly, at the cost of more locking or more work resolving conflicts, which is why almost no database defaults to full Serializable — most workloads don't need it, and the concurrency cost isn't worth paying by default.

ACID and the CAP theorem​

ACID's guarantees, and strict isolation in particular, sit naturally on the CP side of the CAP theorem: serving a genuinely isolated, consistent view of the data is fundamentally in tension with staying available when replicas can't confirm they agree. This is why sharding and replication complicate ACID in practice: a transaction that used to be trivially atomic and isolated on a single machine has to coordinate across multiple machines once the data it touches is split across shards — the same cost database sharding names explicitly as the price of scaling out a relational database.

System Design Lab

Why this matters in an interview​

"The database is ACID-compliant" isn't a design decision on its own — it's a starting property of whatever relational database you picked. The stronger conversation is about isolation level: naming which anomalies a specific piece of the system can tolerate (a dashboard read that's occasionally a few seconds stale is usually fine at Read Committed) versus which parts genuinely need Serializable (a double-booking check on the last seat in a flight). That's also exactly the same reasoning strong vs. eventual consistency applies at the replication layer — different mechanism, same underlying question of what correctness a specific piece of data actually needs.

Go deeper​

The full lesson includes the sequence diagram in more detail and expands on each isolation level's specific anomalies:

👉 Read the full ACID Transactions lesson — part of the free System Design Lab course.

The three properties​

• Consistency (C) — every read gets the most recent write, or an error. All nodes see the same data at the same time.
• Availability (A) — every request gets a non-error response, with no guarantee it's the most recent write.
• Partition Tolerance (P) — the system keeps working even when network messages between nodes are dropped or delayed.

The part everyone skims past: P isn't optional​

Partitions will happen — cables get cut, switches fail, packets get dropped. Any system that spans more than one machine has to handle that reality eventually. Which means P isn't really a choice you get to opt out of. The actual decision CAP forces on you is what happens during a partition: do you choose consistency, or do you choose availability?

• Choose C: nodes that can't confirm they have the latest data return an error rather than risk serving something stale.
• Choose A: every node keeps answering requests, even if some of them serve slightly outdated data.

There's no third option where you keep both during an actual partition — that's the whole theorem.

The nuance most explanations miss​

Most of the time, there's no partition happening. The tradeoff you're actually managing day to day is closer to latency vs. consistency: requiring every replica to confirm a write before acknowledging it (strong consistency) adds latency compared to acknowledging as soon as one node has it (eventual consistency). This is captured by the follow-up framing, PACELC: if Partitioned, choose Availability or Consistency; Else, choose Latency or Consistency.

One more distinction worth being precise about: "consistency" in CAP is a narrower, stricter guarantee than the "C" in ACID database transactions. They're related, but conflating them is a common mistake.

Why this matters in an interview​

"We chose AP for availability" is a weak answer on its own. A stronger one names what specifically breaks during a partition, and why the application can tolerate it — e.g., a social media feed can serve slightly stale data during a partition (choose A), but a payments ledger generally can't (choose C). Naming the actual tradeoff, not just citing the theorem, is what shows real understanding.

Go deeper​

The full lesson has a decision diagram, walks through why "CA" systems are mostly a red flag in interview answers, and covers the pros/cons of choosing AP over CP with concrete examples:

👉 Read the full CAP Theorem lesson — part of the free System Design Lab course.

Why retrying everything makes a bad situation worse​

A struggling service gets hit with the same load (or more, from retries) exactly when it's least able to handle it, while every caller wastes time and resources waiting on calls that are very likely to fail anyway. A circuit breaker wraps calls to a dependency, watches the failure rate, and once failures cross a threshold, stops sending traffic to that dependency entirely for a while — failing fast instead of piling on.

The three states​

The pattern borrows its name, and its state machine, directly from the electrical original:

System Design Lab

• Closed — the normal state. Calls flow through, and the breaker tracks the failure rate.
• Open — once failures exceed a threshold, the breaker trips: for a cooldown period, it fails every call immediately, without even attempting to reach the struggling dependency. This is the core value — protecting the caller from wasted waiting, and the callee from added load on top of whatever's already wrong.
• Half-open — after the cooldown, the breaker cautiously lets a small number of test calls through. If they succeed, it closes and resumes normal traffic; if they still fail, it reopens and waits another cooldown before trying again.

Failing fast is the entire point​

Without a breaker, a caller waiting on a slow, failing dependency ties up its own resources — connections, threads, request-handling capacity — for however long that call takes to time out. If enough callers pile up waiting the same way, the caller can fail too, purely from resource exhaustion, even though its own logic was fine. This is exactly the cascading-failure scenario a circuit breaker exists to interrupt: by failing immediately once the breaker is open, a caller gets an instant, predictable failure and can fall back to a default response, a cached value, or a graceful error, far faster than waiting out a real timeout.

Where it lives in a real system​

A circuit breaker naturally wraps any single outbound call to a dependency — a service-to-service call, a database query, a call to a third-party API. It's a natural fit for an API gateway to own, since every downstream call in a system tends to flow through it anyway, making it a convenient single place to track per-dependency failure rates without instrumenting every individual service that makes the call.

Reacting vs. preventing: circuit breaker vs. rate limiting​

Both are protective patterns that reject requests under stress, but they solve different problems. Rate limiting protects a service from being overwhelmed by too much legitimate demand — it's proactive, rejecting requests before they'd exceed a known-safe capacity, and doesn't require anything to actually be broken yet. A circuit breaker instead protects callers from a dependency that's already failing, reacting to observed failures rather than anticipating load. Many real systems use both together: rate limiting on the way in, circuit breakers on every outbound call to their own dependencies.

Why this matters in an interview​

Any design involving a call to another service or third-party dependency benefits from naming a circuit breaker as the answer to "what happens if that dependency is slow or down." Naming the three states and the half-open recovery step specifically — not just "we'll add a circuit breaker" — signals you understand the mechanism, not just the vocabulary.

Go deeper​

The full lesson expands on tuning failure thresholds and cooldown periods for real dependencies:

👉 Read the full Circuit Breaker lesson — part of the free System Design Lab course.

What a shard actually is​

A shard is an independent, self-contained piece of a split-up database — its own instance, holding its own subset of the rows, capable of answering queries on its own without talking to any other shard for most operations. Which shard a given row lives on is decided by a shard key: a field on the row (often something like user_id) that gets run through a function to decide its home shard. Every query needs that shard key to know where to even look, which is the first cost sharding imposes: you can no longer just query "the database" — you have to know, or compute, where the data lives.

Range-based sharding​

The simplest approach: assign contiguous ranges of the shard key to each shard — user IDs 1–1,000,000 on shard A, 1,000,001–2,000,000 on shard B, and so on. It's easy to reason about and easy to implement, but it has an obvious failure mode: if activity isn't evenly distributed across the key range, some shards end up far hotter than others. A shard holding the newest user IDs in a fast-growing product, or the most active accounts in a range, can become a bottleneck while other shards sit mostly idle.

Hash-based sharding​

The alternative: run the shard key through a hash function and use the result to pick a shard. This spreads load far more evenly, since a good hash function doesn't preserve the kind of locality that creates hot spots. The cost is that range queries — "give me all users created this week" — become expensive, since consecutive keys are now scattered across every shard instead of sitting together. Hash-based sharding is typically paired with consistent hashing, which minimizes how much data has to move around when a shard is added or removed.

What sharding costs you​

Splitting data across machines doesn't just add operational complexity — it changes what kinds of queries and transactions are even reasonably possible:

• Cross-shard queries and joins get expensive. A query that needs data from two different shards has to fan out to both and merge results in application code, instead of letting one database engine do it internally.
• Cross-shard transactions lose easy ACID guarantees. A transaction touching rows on two different shards needs a distributed transaction protocol (like two-phase commit) to stay atomic — meaningfully more complex, and slower, than a transaction that stays on one machine.

This is exactly why choosing a good shard key matters so much: a key that keeps related data — the rows a typical query actually needs together — on the same shard avoids paying this cost on the common path. user_id is a common choice specifically because most queries a product makes are scoped to one user anyway.

Why this matters in an interview​

"We'll shard the database" is an incomplete answer on its own. A stronger one names the shard key and defends it (why this key, and why it keeps related data together), names the sharding strategy (range vs. hash, and the hot-spot tradeoff that choice implies), and is upfront about what gets harder as a result — cross-shard joins and transactions specifically. This is often where a strong vs. eventual consistency discussion follows naturally, since sharded systems frequently relax consistency to avoid the cost of coordinating across shards on every write.

Go deeper​

The full lesson includes a diagram of how a shard key routes a request to its shard, and walks through the range vs. hash tradeoff in more depth:

👉 Read the full Database Sharding lesson — part of the free System Design Lab course.

The quick answer​

Reach for vertical scaling when​

• You need headroom fast and don't want to touch the architecture — it requires zero code changes.
• The system is still small enough that "biggest available machine" is nowhere close to being a real ceiling.

Reach for horizontal scaling when​

• You've hit (or can see) the ceiling on vertical scaling, or downtime for resizing is no longer acceptable.
• You need redundancy — a single machine, no matter how big, is still a single point of failure.
• The workload can actually be split across machines — this is the real precondition people skip.

What horizontal scaling actually costs​

It's not "more complex" in some vague sense — it's specific: every request now has to be routable to any instance, which means nothing about handling it can depend on state that only exists on one machine. A session, an in-memory cache, a WebSocket connection — each either needs to move to a shared store every instance can reach, or the system needs sticky routing, which reintroduces some of the coordination cost horizontal scaling was supposed to avoid. This is the same stateful vs. stateless tradeoff that shows up everywhere once you scale out.

The real-world pattern: vertical first, then horizontal​

Almost no system picks one exclusively. The common, sensible order is: scale vertically first, because it's cheap and requires no architectural work, until the ceiling (or the downtime cost) starts to hurt — and only then invest in the real engineering work horizontal scaling requires. Databases follow this exact same progression.

Why this matters in an interview​

"We'll scale horizontally" as a reflex undersells the tradeoff. A stronger answer names what would actually need to change to make the workload in the prompt statelessly splittable — session storage, cache externalization, whatever it is — rather than assuming horizontal scaling is a free lever to pull.

Go deeper​

The full lesson has a decision diagram and a precise breakdown of what makes a workload "splittable" in the first place:

👉 Read the full Vertical vs Horizontal Scaling lesson — part of the free System Design Lab course.

The six steps​

1. Clarify requirements — what does this system actually need to do, and what's explicitly out of scope?
2. Estimate scale — rough numbers for users, requests per second, and data volume, since scale changes which architecture is even reasonable.
3. Design the API — the concrete contract between clients and your system, before you design what's behind it.
4. Model the data — what entities exist, and how are they shaped and related?
5. Sketch the high-level design — the boxes and arrows: services, databases, caches, queues, load balancers.
6. Deep-dive and discuss tradeoffs — pick the one or two hardest parts and go deep, naming what you gave up and why.

Skipping straight to step 5 — drawing boxes before you know what you're building for — is the most common failure mode. It produces a generic-looking architecture that doesn't actually fit the problem, because nothing about it was derived from a real requirement or a real number.

Why requirements come first​

"Design a URL shortener" sounds fully specified, but it isn't. Does it need custom aliases? Analytics on click-through? Do links expire? Every one of those answers changes the design. Asking clarifying questions isn't stalling — it's the only way to design for the actual problem instead of an imagined generic version of it. It also directly shapes step 2: you can't estimate scale for a system whose scope you haven't pinned down.

Why scale estimation isn't just for show​

Rough numbers — "let's say 100 million daily active users, 10,000 writes per second at peak" — aren't decoration. They're what tells you whether a single relational database is fine or whether you need to talk about sharding at all. A design that reaches for a distributed, sharded architecture to handle 50 requests per second is over-engineered; a design that proposes a single Postgres instance for a system doing 500,000 writes per second is under-engineered. The numbers are what let you defend why your design is sized the way it is, rather than defaulting to whatever's trendiest.

API before architecture​

Designing the API — the actual request/response shapes a client would call — before drawing any boxes forces you to be concrete about what the system does, from the outside, before you decide how it does it internally. It's also just good API design discipline: get the contract right first, and the implementation has a clear target to satisfy.

The deep-dive is where interviews are actually won or lost​

The first five steps get you to a reasonable, defensible baseline design. The deep-dive is where you show real engineering judgment: picking the one or two genuinely hard parts of the problem — how do we handle a hot shard, how do we keep the feed consistent under concurrent writes, how do we deduplicate at-least-once message delivery — and reasoning through them out loud, including the tradeoffs you're accepting. This is also where topics like database sharding, strong vs. eventual consistency, and rate limiting tend to show up as the specific mechanism you reach for.

What's actually being evaluated​

There is no single "correct" architecture for "design Twitter." Interviewers are grading how you navigate tradeoffs, not whether you land on some canonical diagram. A candidate who clearly names why they chose eventual consistency for a like counter, or why they'd shard by user ID instead of by post ID, is demonstrating exactly the skill the interview exists to test — even if a different, equally defensible design was possible.

Go deeper​

The full lesson walks through each step in more detail, includes a flowchart of the framework, and links out to the specific concepts — APIs, SQL vs. NoSQL, load balancing — that tend to come up inside each step:

👉 Read the full How to Answer a System Design Interview Question lesson — part of the free System Design Lab course.

The quick answer​

Layer 4: fast and protocol-agnostic​

An L4 load balancer routes based on connection info alone — it doesn't need to know or care that the traffic is HTTP, or anything else. That makes it fast and simple, at the cost of not being able to make any decision based on what's actually inside the request.

Layer 7: reads the request, pays for it​

An L7 load balancer terminates the connection and inspects the actual request before deciding where it goes. For HTTP, that means URL paths, headers, and cookies — enabling content-aware routing (/api/* to one pool, /static/* to another) and sticky sessions. The cost is real: more CPU work and higher latency per request, since the proxy has to actually parse the application-layer protocol.

L7 isn't only about HTTP​

This is the part most explanations leave out. "Application layer" means whatever protocol is actually running — and a load balancer built to parse that protocol can make the same kind of smart decision on it:

• Databases — tools like ProxySQL (MySQL) and pgpool-II (PostgreSQL) read the query itself, routing SELECTs to read replicas and writes to the primary.
• Caches — protocol-aware proxies like Twemproxy understand Redis/Memcached well enough to shard keys consistently across a cluster.
• VoIP — SIP-aware proxies route calls by parsing the actual signaling protocol, not just IP and port.

Same tradeoff every time: understand more of the traffic, make a smarter routing decision, pay more CPU per request for it.

How it picks which server​

Once a load balancer decides it's routing to a pool, it still needs a policy for which one — round robin, least connections, or consistent hashing (so the same client keeps hitting the same server, keeping that server's local cache warm). The algorithm matters as much as the layer.

Why this matters in an interview​

Naming the layer and the algorithm — "an L7 load balancer with least-connections, since request durations vary a lot here" — is a specific engineering decision, not a generic "we'll add a load balancer." That specificity is what separates a real answer from a diagram with a box labeled "LB."

Go deeper​

The full lesson has a health-check diagram, the full routing-algorithm comparison table, and diagrams for the database and cache examples above:

👉 Read the full Load Balancing lesson — part of the free System Design Lab course.

Not the same job as load balancing​

It's worth being precise about the difference: load balancing assumes the incoming traffic is legitimate and spreads it out efficiently. Rate limiting assumes some incoming traffic might be excessive or abusive, and its job is to say no to some of it — typically with an HTTP 429 Too Many Requests — before it ever reaches real business logic.

Why a service needs this at all​

Without a limit, one misbehaving client — a buggy retry loop, a scraper, a deliberate abuser — can consume a disproportionate share of a service's capacity, degrading it for everyone else. It's the standard first line of defense against basic denial-of-service traffic, and a practical necessity for metering usage on any API with paid tiers. Rate limiting is typically enforced once, centrally, at an API gateway — so individual backend services don't each have to reimplement the same logic, and a request that's going to be rejected anyway never costs the backend any real work.

The algorithms​

System Design Lab

Why token bucket is the go-to answer​

Token bucket is the most commonly cited algorithm in interviews because it fits how real traffic actually behaves: legitimate clients are often bursty — a page load firing off several requests at once — and token bucket tolerates that burst as long as the average rate stays within budget. Fixed window, by contrast, either lets through a burst it shouldn't (right at a window boundary) or blocks a burst that was actually fine.

What key you limit on matters as much as the algorithm​

The algorithm decides how to count; the key decides who's being counted. Per-IP limiting can unfairly throttle many legitimate users sitting behind the same corporate NAT or proxy, while per-user or per-API-key limiting is more precise but only works once a client is authenticated — which is why public, unauthenticated endpoints often fall back to IP-based limiting as a coarser first line of defense.

Tell the client where it stands​

A well-designed rate-limited API doesn't just reject silently at the threshold — it signals via response headers like X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset, so a well-behaved client can back off proactively instead of hammering the API until it gets a 429. It's a small detail, but naming it signals you're thinking about the client's experience of the limit, not just the server's enforcement of it.

Why this matters in an interview​

"We'll add rate limiting" is weak on its own. Naming the algorithm (token bucket, for bursty-but-bounded traffic), where it's enforced (the gateway, so rejected requests cost the backend nothing), and what key it's keyed on turns it into a specific, defensible decision. It's also the natural complement to a circuit breaker — rate limiting protects a service from too much legitimate demand coming in, while a circuit breaker protects callers from a dependency that's already failing going out.

Go deeper​

The full lesson expands on each algorithm's boundary behavior and where rate limiting fits inside an API gateway:

👉 Read the full Rate Limiting lesson — part of the free System Design Lab course.

The quick answer​

Reach for REST when​

• It's a public API, a CRUD-shaped resource, or anything that benefits from standard HTTP caching, versioning, and tooling that already assumes REST (most API gateways and monitoring do).
• You have one kind of client and its data needs are fairly uniform.

Reach for GraphQL when​

• You have genuinely different clients wanting different slices of the same data — a web app, an iOS app, and a smartwatch app each needing their own shape is the textbook case.
• The team can afford building the server-side resolver and batching layer GraphQL requires.

The tradeoff most comparisons skip: caching​

This is the one that actually matters for a system design decision. REST's one-URL-per-resource model means a browser, CDN, or reverse proxy can cache a GET /users/42 request with zero extra work — caching is a property of the protocol itself. GraphQL typically exposes a single endpoint reached via POST, which means none of that standard caching infrastructure applies automatically. A GraphQL server has to build its own caching (normalized client-side caches like Apollo, or persisted queries) — real engineering work that REST gets for free.

The other GraphQL-specific cost worth knowing: the N+1 problem. Naively resolving a nested query (a list of users, each resolving its own orders) fires one database query per item instead of one batched query for everyone — unless the server explicitly batches those resolutions.

The real-world answer: often both​

Many production systems use REST at the edge for simple, cacheable resources, and GraphQL for one specific client-facing aggregation layer that genuinely needs to serve different shapes to different clients — not one or the other for the whole system.

Go deeper​

The full lesson has a diagram comparing the request shapes directly, walks through the N+1 problem with a concrete example, and gives the interview framing for defending whichever choice you make:

👉 Read the full REST vs GraphQL lesson — part of the free System Design Lab course.

The quick answer​

Neither row is "better" — they're optimized for different problems.

Reach for SQL when​

• The data is naturally relational (orders, customers, inventory, payments) and you'll need to join across it.
• Correctness matters more than raw throughput — a financial ledger can't tolerate "eventually consistent."
• You don't fully know your query patterns yet. A fixed schema with joins gives you the flexibility to ask new questions later; a denormalized NoSQL store only answers the questions it was shaped for.

Reach for NoSQL when​

• The data is naturally document- or key-value-shaped, and its structure varies or evolves quickly.
• You already know your access patterns well enough to denormalize around them.
• Horizontal scale or write throughput matters more than ad hoc query flexibility.

Why NoSQL usually scales out more easily​

This is the part most comparisons skip: it's not that NoSQL databases are "faster" in some general sense. It's that avoiding cross-record joins and relaxing strict consistency means related data can live entirely within one shard, so shards rarely need to coordinate with each other. A relational database's join or transaction, by contrast, might need data sitting on a different machine entirely — which is expensive to coordinate at scale. Modern relational systems (distributed SQL like Spanner or CockroachDB) have narrowed this gap a lot, but the underlying tension is still there.

The real-world answer: often both​

Most systems at any real scale use a relational database for their core transactional data, and a NoSQL store for one specific high-scale pattern — a product catalog, a session store, an activity feed — rather than picking one for the entire system.

Go deeper​

This post is the short version. The full lesson covers the CAP theorem tradeoff NoSQL databases are actually making, walks through why denormalization enables sharding with a diagram, and gives the interview framing for defending whichever choice you make:

👉 Read the full SQL vs NoSQL lesson — part of the free System Design Lab course.

Stateless: every request carries what it needs​

A stateless server treats each incoming request as fully self-sufficient — everything needed to handle it (an auth token, the relevant IDs, the data itself) travels with the request, and the server keeps nothing about the client in its own memory afterward. This pairs naturally with horizontal scaling: because any stateless server instance can handle any request equally well, a load balancer can route traffic to whichever instance is least busy, with no need for "sticky" routing that pins a client to one specific server.

Stateful: the server remembers you​

A stateful server holds context about a specific client in its own memory between requests — a session object, an in-progress multi-step operation, an open connection. This makes certain interactions simpler to reason about, but it means a client generally has to keep talking to that specific server instance for the interaction to keep working, which is exactly the sticky-routing requirement statelessness avoids.

System Design Lab

Statelessness doesn't mean state disappears — it means it moves​

This is the part that trips people up: a stateless architecture doesn't mean the application has no state at all — a shopping cart, a user's session, a logged-in identity are all still real state that has to live somewhere. What changes is where. Instead of living in one server's process memory, it moves to a shared store every server instance can reach equally — a database, a distributed cache like Redis, or an encoded, signed token (a JWT) the client carries and presents on every request. Any server can then serve any request, because the state it needs isn't tied to which server happened to handle the client last.

The resistant case: WebSockets​

Not everything can be made stateless cleanly. A WebSocket connection is a genuine counterexample: the open, persistent connection between a specific client and a specific server is the state — there's no way to externalize "this TCP connection is open" to a shared database the way you can externalize a session token. Real-time systems built on WebSockets typically need sticky routing (or a connection-aware layer that can route messages to whichever server actually holds the relevant socket) precisely because this one piece of state can't be moved out of the server holding the connection.

Why this matters in an interview​

Defaulting to stateless design is usually the right instinct for anything expected to scale horizontally — it's what makes adding more servers behind a load balancer actually work without extra coordination. But naming where the externalized state goes (which store, and why it's fast enough not to become the new bottleneck) is what separates a real answer from just saying "make it stateless." And naming WebSockets — or any other case where state genuinely can't move — as the exception shows you understand the tradeoff isn't universal, just usually correct.

Go deeper​

The full lesson goes deeper on session storage options and where sticky routing legitimately earns its place:

👉 Read the full Stateful vs Stateless Design lesson — part of the free System Design Lab course.

Strong consistency: every read sees the latest write​

Under strong consistency, a write isn't acknowledged until enough replicas confirm they have it, and a read afterward is guaranteed to reflect it — there's no window where a client could read stale data right after a confirmed write. This is the C side of the CAP theorem: strong consistency is what a CP system chooses to preserve, typically at the cost of added write latency (waiting on replicas) or reduced availability (if enough replicas can't be reached, the write has to fail rather than risk an inconsistent read later).

Eventual consistency: fast ack, catch up later​

Under eventual consistency, a write is acknowledged as soon as it lands somewhere — often just one node — and the update propagates to other replicas afterward, typically via mechanisms like Change Data Capture. In the meantime, a read against a replica that hasn't caught up yet can return stale data. What "eventual" actually promises is narrower than it sounds: if no new writes happen, all replicas will converge to the same value — it just doesn't say when.

System Design Lab

Where weaker guarantees are chosen on purpose​

A social media like counter is the canonical case for choosing eventual consistency deliberately, not out of laziness: if a "like" briefly shows 4,201 instead of 4,202 on one replica for a few hundred milliseconds, nobody is harmed and almost nobody notices. What that system gets in exchange is much lower write latency and much higher availability, since it never has to stall a write waiting on every replica to agree.

Where strong consistency earns its cost​

A bank balance is the opposite case. If a withdrawal is confirmed but a concurrent read against a stale replica shows funds that were already spent, that's not a rounding error — it's a double-spend risk. Inventory counts for a limited item during a flash sale have the same shape: sell the same last unit twice because two replicas disagreed briefly, and you've made a promise you can't keep. These are exactly the cases where paying strong consistency's latency cost is the correct trade, not an overcautious one.

It's a spectrum, not a binary switch​

Real systems usually don't pick one extreme globally. Read-your-own-writes consistency guarantees a client always sees its own recent write, even if other clients might briefly see something older — a common middle ground for user-facing apps. Quorum-based systems tune this directly with numbers: with N replicas, requiring W nodes to acknowledge a write and R nodes to agree on a read, setting W + R > N guarantees every read overlaps with the most recent write, letting you dial consistency and latency against each other rather than choosing one extreme for the whole system.

Why this matters in an interview​

Naming "we chose eventual consistency" is incomplete without naming why the specific data can tolerate it — and just as importantly, naming which parts of the same system can't. A well-designed system frequently uses both: eventual consistency for a feed or a counter, strong consistency for the parts that touch money or inventory, exactly as the CAP theorem framing would predict once you look at each piece of data individually instead of the system as a whole.

Go deeper​

The full lesson expands on quorum tuning and read-your-own-writes with more worked examples:

👉 Read the full Strong vs Eventual Consistency lesson — part of the free System Design Lab course.

Synchronous: call, wait, continue​

A synchronous call blocks the caller until a response comes back — an ordinary API request is the default example: send, then do nothing else until the response (or a timeout) arrives. It's simple to reason about, since code reads top to bottom and each line's result is known before the next runs. But it directly couples the caller's responsiveness to the callee's: if the callee is slow, the caller is slow; if the callee is down, the caller is stuck waiting — exactly the failure mode a circuit breaker exists to cut short.

Asynchronous: send, move on, find out later​

An asynchronous call doesn't wait — the caller triggers something (publishing to a message queue, emitting an event) and continues immediately, finding out the result later if it needs to at all. This decouples the caller's responsiveness from the callee's entirely: a slow or temporarily unavailable consumer doesn't block the producer, since the queue or event bus absorbs the gap.

System Design Lab

The real question: does the caller need the answer right now?​

Stripped to its core, this is the entire decision. If the caller genuinely needs the result before it can do anything else — checking whether a login succeeded before showing an account page — synchronous is the natural, honest fit, and forcing it asynchronous just adds complexity (polling, a callback) to simulate waiting, for no real benefit. If the caller doesn't need the result immediately — logging an analytics event, sending a confirmation email after signup — synchronous is the wrong default, needlessly coupling the caller's response time to a task it doesn't actually need finished yet.

Every specific pairing is a version of this one choice​

Long polling vs. WebSockets is about how a client finds out about server-side changes — poll synchronously and repeatedly, or receive asynchronously as they happen. Push vs. pull architecture is the same question about who initiates. Event-driven architecture is choosing asynchronous, event-based communication as a whole system's default integration style rather than direct synchronous calls between every service. Recognizing that these are all the same underlying question is what turns a handful of memorized pairs into one coherent way of reasoning about a new tradeoff the moment it comes up.

What asynchronous communication actually costs​

Trading away "wait and know the result immediately" isn't free. A caller that doesn't wait for a result needs a different way to find out about failures — a dead-letter queue, a retry policy — and any operation whose result matters eventually needs idempotency to safely handle the at-least-once delivery that pattern typically implies. Asynchronous communication buys decoupling and resilience to a slow downstream dependency, at the cost of that extra infrastructure and the complexity of answering "how do I find out what actually happened" — a question a synchronous call answers automatically, just by returning.

Why this matters in an interview​

Every service-to-service interaction in a design is worth explicitly labeling synchronous or asynchronous, and justifying it by whether the caller genuinely needs the result before proceeding. It's the thread connecting nearly every communication-pattern tradeoff in this course into one coherent way of reasoning, rather than a pile of separately memorized pairs.

Go deeper​

The full lesson ties this back to every other communication tradeoff in the course, closing out the System Design Tradeoffs module:

👉 Read the full Synchronous vs Asynchronous Communication lesson — part of the free System Design Lab course.

The quick answer​

What TCP actually does to earn "reliable"​

TCP opens every connection with a three-way handshake (SYN, SYN-ACK, ACK) before a single byte of real data moves, which is real latency spent up front in exchange for a guarantee. Every segment gets a sequence number, the receiver acknowledges what it got, and anything unacknowledged within a timeout gets retransmitted — so data arrives complete and in order, or the connection reports a failure. TCP also runs congestion control, backing off its send rate when it detects loss, so it behaves cooperatively on a shared network instead of hammering it.

What UDP does instead: almost nothing, on purpose​

UDP has no handshake, no sequence numbers, no acknowledgments, no retransmission, and no congestion control. A sender just fires packets; if one is dropped, nobody notices at the transport layer — it's simply gone. This sounds like a strictly worse protocol until you consider what it buys: near-zero setup latency (no handshake to wait on) and a much smaller header, which matters when you're sending many small, time-sensitive packets.

The real question: is a late packet worse than a lost one?​

This is the actual decision, and it's the reason UDP exists at all. For a video call, a frame that arrives 400ms late is useless — the moment it was meant to represent has already passed, and TCP-style "wait and retransmit" logic would just add growing delay for stale data nobody wants. Dropping that frame and moving on to the next one, which is exactly what UDP-based protocols do, produces a better user experience than perfect, ordered, retransmitted delivery. The same logic applies to live audio, to gaming, and to DNS — a UDP-based DNS query that gets no response can just be reissued immediately, which is often faster than waiting for TCP's own retransmission timers.

Why HTTP/3 picked UDP​

Modern HTTP/3 is built on QUIC, which runs over UDP rather than TCP — deliberately. TCP's ordering guarantee has a side effect called head-of-line blocking: if one packet is lost, everything behind it in the stream has to wait for the retransmit before the application sees any of it, even data for a completely unrelated request multiplexed on the same connection. QUIC implements its own reliability and ordering on top of UDP, but per-stream instead of per-connection, so one lost packet only blocks the stream it belongs to. It's a case of taking UDP's minimal transport and rebuilding just the pieces of TCP's guarantees that are actually needed, without the parts that hurt.

Why this matters in an interview​

Naming "TCP" or "UDP" alone is a weak answer. The stronger one names why the specific workload tolerates loss or doesn't: a chat message needs guaranteed, ordered delivery (TCP), a live video stream tolerates a dropped frame far better than a delayed one (UDP), and a file upload absolutely cannot silently drop bytes (TCP). That reasoning — not the protocol name — is what the interview is actually testing.

Go deeper​

The full lesson includes a sequence diagram comparing the TCP handshake against UDP's connectionless send, and goes deeper on where each protocol shows up in real systems:

👉 Read the full TCP vs UDP lesson — part of the free System Design Lab course.

The hard floor no server can optimize away​

Even at the speed of light, a round trip between New York and Sydney costs over 100ms from distance alone, before either server does a millisecond of actual work. No amount of backend optimization changes that — it's a physical constant, not an engineering problem. A CDN's entire value proposition is sidestepping it: instead of every request traveling all the way to one origin server, it travels to whichever edge server (or point of presence) is geographically nearest, and only that edge server occasionally talks back to the origin.

System Design Lab

How a user actually reaches the nearest edge​

Getting each user routed to their closest edge location is itself a solved problem, built on infrastructure this course already covers: geo-DNS resolves the same domain name to a different IP address depending on where the query originated, pointing a user at the nearest edge before a single byte of the real request is sent. It's the same DNS-based load-balancing idea from ordinary load balancing, just applied at planetary scale instead of within one datacenter.

Static content is the easy case — dynamic content isn't​

CDNs were built for, and remain best at, static content: images, video, CSS, JS bundles — anything identical for every user that changes infrequently. That content can sit at the edge behind a simple TTL and get served without ever touching the origin. Dynamic, personalized content — a user's own account page, a live search result — is a much harder fit: caching it at the edge risks serving one user's private data to someone else, so CDNs either skip caching it entirely (proxying straight through) or use narrower techniques like edge computing to personalize responses without a full round trip home.

A side effect worth naming: origin protection​

Because most cacheable requests get absorbed at the edge, the origin server only ever sees cache misses and genuinely dynamic traffic — often a small fraction of the total. It's the same load-shedding effect any cache has on the system behind it, just operating at the scale of an entire global user base. It also happens to be a meaningful defense against traffic spikes and some categories of denial-of-service traffic, since the public-facing surface is the CDN's much larger edge fleet, not the origin itself.

Push vs. pull​

CDNs populate edge caches one of two ways: pull, where an edge server lazily fetches and caches content the first time it's requested (the standard cache-aside pattern, applied at the edge), or push, where content is proactively uploaded to every edge location ahead of time. Pull is the simpler default; push is used when content has to be guaranteed present before the first request — a scheduled video release, for instance.

Why this matters in an interview​

Any design serving a geographically distributed audience — especially one with real static assets — should name a CDN explicitly rather than leaving "the client fetches this over the internet" implicit. Just as important: being ready to draw the static/dynamic line, naming which parts of a design a CDN genuinely helps and which parts still have to hit the origin, is what separates a real answer from name-dropping "CDN" as a buzzword.

Go deeper​

The full lesson covers push vs. pull CDNs in more depth and connects back to the general push/pull architecture tradeoff:

👉 Read the full CDN lesson — part of the free System Design Lab course.