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 7-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”
You're a fintech company with an office in New York and another in London. Both offices need to read and write customer data throughout the business day. With a single primary in New York, the London office eats 70ms of on every write. With a single primary in London, New York suffers the same.
Bidirectional is the answer: set up a writable database in each location, and have them replicate to each other. New York writes go to New York's database and are sent to London. London writes go to London's database and are sent to New York. Both sides always have the full dataset.
This is the smallest possible multi-master setup, just two nodes. And because it's only two nodes, the conflict surface is smaller and easier to reason about than a full multi-master cluster with five or ten peers. Oracle GoldenGate, MySQL Group Replication, and PostgreSQL's BDR (Bi-Directional Replication from 2ndQuadrant/EDB) all support this pattern.
Many companies that claim to "do multi-master" are actually running bidirectional replication between two data centers or two cloud regions. It's enough for most use cases and dramatically simpler than managing conflicts across many nodes. Stripe runs a form of bidirectional replication between US regions for payment processing resilience.
Both nodes run the full application stack. Both accept reads and writes. Each node has a process that:
That last point is critical. Without loop detection, a write on Node A would replicate to Node B, which would replicate it back to Node A, which would send it back to Node B, forever. Every bidirectional replication system includes a mechanism to identify the origin of a change and skip re-replication.
Common loop-prevention techniques:
server_id in the binlog.SET SESSION replication_origin = 1) that suppresses trigger-based capture.pg_replication_origin so that applied changes are tagged and not re-forwarded.Conflict scenarios specific to bidirectional:
| Scenario | What Happens | Typical Resolution |
|---|---|---|
| Same row updated on both sides | Both changes arrive at the other node | LWW, merge, or flag for review |
| Row deleted on A, updated on B | B receives a delete for a row it just modified | Usually: delete wins (configurable) |
| INSERT with same PK on both sides | Both nodes create a row with the same ID | Use UUIDs or prefixed sequences to prevent |