Replication
Your whole system trusts one database. What happens the day that one machine catches fire? Your data is gone, and the site is down. The fix is simple to say: don't keep just one copy — keep several, on different machines. That's replication. It buys you two big things (safety and more reading power) and hands you one tricky catch (the copies can drift a moment out of date).
Replication = keeping copies of your data on more than one machine
Replication means storing the SAME data on several machines at once. Each machine holds a full copy of the database — not a piece of it, the whole thing. Think of an important phone number. If you write it on one sticky note and lose it, it's gone forever. If you copy it into three notebooks kept in three different rooms, losing one notebook is no big deal — the number still exists. Replication does exactly that for your database: many notebooks, same contents.
Why bother? Two reasons: don't lose data, and serve more readers
Reason one is safety. If a machine dies — a disk fails, the power goes — and that machine held your only copy, your data is lost and your app is down. With copies on other machines, one dying is survivable: another copy takes over and nobody loses anything. Reason two is speed under load. Most apps read data far more often than they change it (think how many people VIEW a post versus how many WRITE one). If you have five copies, five machines can answer 'read' requests at the same time, instead of one machine drowning under everyone's questions. More copies = more reading power.
The leader/follower setup: writes go to one boss, copies fan out
If everyone could change any copy, the copies would quickly disagree and you'd have chaos. So the common rule is: pick ONE copy to be the boss — the leader — and the rest are followers. All the writes (anything that CHANGES data: a new order, an edited profile) go to the leader. The leader then copies each change out to every follower, so they stay up to date. Reads (just looking at data) can come from any follower. That's the whole trick: one place to change things keeps everyone in agreement, while many places to read things spreads the load.
The catch: replication lag — a follower can be a moment behind
Copying takes a tiny bit of time. After you write to the leader, there's a brief moment before that change reaches all the followers. That gap is called replication lag. Here's why it matters. Imagine you post a comment (written to the leader), then immediately refresh the page — and your refresh happens to read from a follower that hasn't received the copy yet. Your comment seems to vanish! It's not lost; the follower is just a half-second behind. So replication gives you a system where a reader can briefly see slightly OLD data. Deciding how much that's allowed to happen — and what to do about it — is a whole big idea called consistency, which the CAP theorem topic digs into.
It's a tradeoff
| Option | 👍 Pro | 👎 Con |
|---|---|---|
| One copy (no replication) | Dead simple — one place for everything, never any disagreement between copies. | If that machine dies, the data is lost and the app is down. And one machine has to answer every single read. |
| Leader + followers (replication) | Survives a machine dying, and spreads reads across many copies so the system handles far more readers. | Followers can lag a moment behind the leader, so a reader might briefly see stale data. More machines to run, too. |
Questions you might have
▸Is a copy the same as a backup?
Related, but not the same. A backup is a frozen snapshot you keep aside in case of disaster — usually old, and you have to restore it. A replica is a LIVE copy that's kept up to date constantly and can answer requests right now. Replication is about staying available and fast, not just about recovering after a crash.
▸Why not let people write to any copy? Wouldn't that be even faster?
Because then two copies could be changed differently at the same time and disagree, and now nobody knows which version is correct. Funneling all writes through one leader keeps a single source of truth that everyone copies from. (Some advanced systems do allow many writers, but it's much harder to get right — that's why leader/follower is the common starting point.)
▸What is replication lag, and is my data lost during it?
Lag is the short delay between a change hitting the leader and that change reaching the followers — copying isn't instant. Your data is NOT lost; the leader has it and is sending it out. It just means a reader hitting a follower in that tiny window might see the older version for a moment, until the copy catches up.
▸If a follower can show old data, why use them for reads at all?
Because for most things, a half-second-old answer is totally fine — does it matter if a 'likes' count is briefly off by one? Followers let you serve a huge number of readers cheaply. You only route the rare, must-be-exact reads to the leader. It's a trade: a little staleness in exchange for a lot of reading power.
▸What happens when the leader itself dies?
One of the followers gets promoted to become the new leader, and writes start going to it instead. This switch is called failover. It's the payoff of having copies: losing the boss doesn't lose the data, because a follower already has it and can step up.
Best read after: Stateless vs. stateful