We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Data Replication Distribution
Free preview: the first 2 parts of this 8-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Data Replication Distribution
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Imagine you're running a global SaaS application. Your primary database is in Virginia. A user in Tokyo writes a comment. That write has to travel 11,000 km to Virginia, get committed, and the response has to travel 11,000 km back. That's 200ms minimum, just for physics. For every single write.
Your users in Asia are annoyed. Your users in Europe are annoyed. Everyone who isn't near Virginia is annoyed. The single-master model means all writes funnel through one geographic location, and there's nothing you can do about it in that architecture.
Multi-master removes that bottleneck. You set up writable nodes in Virginia, Frankfurt, and Tokyo. Users write to their nearest node. Each node replicates changes to the others. Writes are fast everywhere.
Google Spanner runs multi-master across 5+ continents. CockroachDB distributes writes across any number of nodes. Amazon DynamoDB global tables accept writes in any AWS region. These systems let you write to any node, and the database handles synchronization.
But here's the catch everyone discovers eventually: when two nodes accept writes simultaneously, they can conflict. User A updates a record on Node 1 while User B updates the same record on Node 2, at the same instant. Both writes succeed locally. When they replicate to each other, which one wins?
That conflict resolution problem is the defining challenge of multi-master replication. I run that exact clash on two real CouchDB servers in the conflict resolution lesson.
Every node in a multi-master setup is a full peer. Each can accept reads AND writes. Changes are replicated to all other nodes asynchronously (or synchronously in systems like Spanner, at a cost).
The flow:
Conflict detection. When a node receives a replicated change, it checks if the same row was modified locally since the change was sent. If it was, that's a conflict. Systems use version vectors, timestamps, or both to determine whether two changes are concurrent (conflicting) or causally ordered (one happened before the other).
Conflict resolution strategies:
| Strategy | How It Works | Pros | Cons | Used By |
|---|---|---|---|---|
| Last-write-wins (LWW) | Highest timestamp wins | Simple, automatic | Can silently discard valid writes | DynamoDB, Cassandra |
| Application-level | App-specific merge logic | Most accurate | Complex to implement | CouchDB, custom systems |
| CRDT-based | Conflict-free data types | Mathematically guaranteed | Limited data structures | Riak, CRDTs |
| Certification-based | Reject conflicting txns | No data loss | Aborted transactions at commit | MySQL Group Replication |
| Manual resolution | Flag for human review | No data loss | Doesn't scale |
Most production multi-master systems default to LWW for simplicity. DynamoDB global tables use LWW. Cassandra uses LWW with microsecond timestamps. MySQL Group Replication uses a certification-based approach that rejects conflicting transactions before they commit.
| Legacy enterprise DBs |