Replication
maang.io System Design Series
Replication keeps copies of your data on multiple machines so the system survives failures and serves reads at scale. The whole subject is choosing who can accept a write and how fast copies converge — single-leader (simple, one writer), multi-leader (write anywhere, resolve conflicts), or leaderless quorums (Dynamo-style). Every choice trades consistency against availability, the CAP tension made concrete.
This deep dive comes in three parts:
- Foundations & Core Concepts — the three replication models and synchronous vs asynchronous.
- Internals — replication logs, lag, read-after-write guarantees, and failover/split-brain, with worked numbers.
- Interview — Staff/Principal Q&A: consistency guarantees, failover reasoning, and model selection.
Replication — Part 3: System Design & Interview Mastery
maang.io System Design Series
What is this?
You now know replication from the branch-ledger picture down to fencing tokens. This chapter turns that into interview points. Interviewers almost never ask "explain replication" directly — instead it hides inside every design question: "how do you scale reads?", "how do you survive a datacenter outage?", "the user says their post disappeared — why?" Each of those is a replication question wearing a costume.
We'll do two things: see where replication decides a design (with diagrams), then run a mock interview — for each question, what they're really asking, a model answer, and the senior line that signals you've operated this in production.
The one-line idea: interviewers use replication to test whether you can reason about copies that disagree — pick a topology for the workload, name the exact consistency guarantee a symptom needs, and stay honest about what you lose when a node dies mid-write.
Sign in to continue reading
The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.
Sign in to read the full lesson