In Module 5, Tiffin's single database got a couple of read replicas, and we dealt with the immediate fallout: lag, failover, backups. That was enough for one city. Tiffin is now a large app in many cities, with dozens of teams, and copies of data are everywhere: database replicas, Redis replicas, Kafka is usually set to keep three copies of every message, the search cluster keeps two of every index.
This module goes underneath all of that. How do copies actually stay in sync? What happens when the machine in charge dies? Can two copies both accept writes? And what does a user actually see while copies disagree? We start with the question that decides most of the answers: why do you want a copy in the first place?
Replication means keeping a copy of the same data on several machines, connected by a network, and keeping those copies up to date as the data changes.
Four reasons to keep copies
People say "we replicate for reliability" as if it's one thing. It's really four, and they pull in different directions.
| Reason | The question it answers | Tiffin example |
|---|---|---|
| Availability | Can we keep serving when a machine dies? | Orders keep flowing when the orders database's server fails at 8:15pm |
| Durability | Can we avoid losing data when a disk dies? | A confirmed payment is never forgotten |
| Read scale | Can more machines share the reads? | 60,000 menu reads a second across many replicas |
| Latency | Can the data sit close to the user? | Customers in London read menus from a London copy, not Mumbai |
Each one needs something different from the copies. Let's take them in turn.