Master-Master Replication

Your application has grown. You have a primary database in Virginia and read replicas worldwide. Reads are fast everywhere. But writes are a different story.

A user in Mumbai updates their profile. That write travels 13,000 km across undersea cables to Virginia, gets processed, and the confirmation travels 13,000 km back. Round trip: 200-300ms minimum. For a simple profile update, that's noticeable. For a real-time collaborative document or a chat application, it's unacceptable.

You could put the primary in Mumbai, but then users in San Francisco get the same latency. You can't win with a single writer.

Master-master replication (also called multi-leader or multi-primary replication) solves this by allowing multiple servers to accept writes simultaneously. Each leader handles writes from nearby users, then exchanges changes with other leaders asynchronously.

It sounds ideal. And for specific use cases, it is. But it comes with a fundamental problem that doesn't exist in single-leader systems: write conflicts. Two leaders can modify the same data at the same time, and now you have two different versions of the truth.

The setup:

• Two or more servers, each acting as both a writer (primary) and a reader
• Each leader accepts writes from clients in its region
• Each leader asynchronously sends its changes to all other leaders
• Each leader applies changes from other leaders to its local copy

Example with two data centers. US-East and EU-West:

1. User in New York writes to US-East leader: UPDATE users SET name = 'Roni' WHERE id = 42
2. User in London writes to EU-West leader: UPDATE users SET email = 'new@email.com' WHERE id = 42
3. US-East sends its change to EU-West. EU-West sends its change to US-East.
4. Both leaders now have both changes applied.

In this example, the writes touched different columns on the same row. No conflict. Easy.

But what if both users updated the same column?

1. US-East: UPDATE users SET name = 'Roni' WHERE id = 42 at timestamp T1
2. EU-West: UPDATE users SET name = 'Ronidas' WHERE id = 42 at timestamp T2

Now US-East has name = 'Roni' and EU-West has name = 'Ronidas'. When they exchange changes, each leader sees a conflicting update. Which one wins?