Multi-Primary Architecture

In a multi-primary topology every node accepts writes. This removes the single-writer bottleneck and the failover gap, and introduces write conflicts — two nodes modifying the same row at the same time.

How conflicts are handled

Certification-based replication (Galera, MySQL Group Replication) broadcasts a transaction's write set to all nodes at commit time. Every node deterministically decides whether it conflicts with a concurrent transaction. Losers are aborted, so a conflict surfaces as a failed commit rather than as silent divergence.

The consequence is that commit latency includes a cluster round trip, and a hot row written from several nodes produces a high abort rate. Galera's practical guidance — direct writes for a given dataset at one node where possible — exists precisely because of this.

Last-write-wins (Cassandra, and asynchronous MySQL ring topologies) accepts both writes and keeps the one with the higher timestamp. Nothing fails, and one update silently disappears. Cassandra applies this per column, so two concurrent updates to different columns of the same row both survive.

What breaks

Multi-primary changes assumptions that application code usually makes implicitly:

• Auto-increment keys. Two nodes will allocate the same value unless the range is partitioned (auto_increment_increment / auto_increment_offset) or you use UUIDs.
• Read-modify-write. Reading on one node and writing on another is not atomic across the cluster. Use conditional updates or route the entity to a single node.
• Uniqueness. In asynchronous multi-primary, two nodes can both accept a row with the same unique value and the conflict appears at replication time, not at insert time.
• Foreign keys and large transactions. Galera in particular has documented limitations on transaction size and requires InnoDB with primary keys on all replicated tables.

When it is worth it

Multi-primary genuinely helps in two situations:

1. Continuous availability with no promotion step. Synchronous multi-primary clusters survive a node loss without a failover procedure, which is valuable when the failover gap itself is the problem.
2. Multi-region writes with region-local latency. When users in different regions write mostly disjoint data, each region can own its writes.

It is not a general answer to write scaling. In a certification-based cluster every node still applies every write, so total write capacity does not grow with node count — you are buying availability, not throughput.