Replication means keeping a copy of the same data on multiple machines that are connected via a network. This is fundamental for building systems that are resilient to hardware failures and geographically closer to users.
- High Availability: System stays up even if one node goes down.
- Disconnected Operation: Allows apps to continue working when network is down.
- Latency Reduction: Placing data closer to users geographically.
- Scalability: Increasing read throughput by distributing queries.
This is the most common approach (used in MySQL, PostgreSQL, MongoDB). One node is designated as the Leader.
- The Leader receives all write requests.
- It writes to its local storage and sends the data change to all Followers.
- Followers apply the changes in the same order.
Synchronous vs. Asynchronous Replication
Synchronous replication guarantees that the follower has a copy, but the write fails if the follower is slow. Asynchronous replication is fast but risks data loss if the leader fails before the follower receives the update.
Popularized by Amazon's Dynamo and used in Cassandra/Riak. There is no leader; any node can accept writes.
To ensure consistency, we use a Quorum. If we have replicas, every write must be confirmed by nodes, and every read must query nodes.
To guarantee that a read sees the latest write, the overlap between the write set and read set must be non-empty:
Commonly, .
| Configuration | w + r > n? | Property |
|---|---|---|
| n=3, w=2, r=2 | 4 > 3 (Yes) | Strong consistency (Read-after-write) |
| n=3, w=3, r=1 | 4 > 3 (Yes) | Heavy write, fast read |
| n=3, w=1, r=1 | 2 > 3 (No) | Fast but inconsistent (Eventual only) |
In the next chapter, we will look at how to handle datasets that are too large to fit on a single node via partitioning.