You may have noticed two issues with the master-replica setup:

• The master is used extensively for database writes, and hence is under constant duress
• The issue of reads has been solved with replicas but the single point of failure for writes is still present

Master-master replication tries to solve these issues by making every database a master. It can be explained as follows:

1. We take a cluster of databases:

2. We designate every database as a master:

3. Reads can be performed from any of the masters:

4. Writes can be performed to any of the masters:

5. Every master updates every other master with the writes:

6. Hence, the state is maintained across all the databases:

It may seem like this strategy works fine, but it has its own limitations and challenges; the major one being conflict resolution between writes. Here's a simple example.

We have two master-master databases DB-1 and DB-2, and both have the latest state of the database system:

We have two simultaneous write operations to perform, so we send "Bob" to DB-1 and "Alice" to DB-2.

Now that both databases have written the data to their tables, they need to update the other master with its own latest state:

This will lead to conflict because in both tables, ID# 3 is populated with Bob for DB-1 and Alice for DB-2:

In reality, the master-master strategy would have in-built mechanisms to deal with these kinds of issues, but they may induce a performance penalty or other challenges. This is a complex subject and we have to decide on what trade-offs are worth making if we want to use master-master replication.