Stackbook Logo
data-consistencyestablished · high operational burden

Multi-Leader Replication

Also known as: active-active-replication, master-master, multi-master

Intent

Accept writes at several nodes or regions and replicate them to each other to gain local write latency and regional availability.

Problem

A single leader forces all writes through one region, adding latency for distant users and creating a single failure point for writes. Yet independent writers can update the same data concurrently. The system must reconcile such conflicts.

Forces

  • •Low write latency in every region
  • •Writes must continue if a region is cut off
  • •Concurrent updates to the same record will conflict
  • •Replication loops and ordering must be handled

Solution

Overview

In multi-leader, or active-active, replication every region has a node that accepts writes. Each leader replicates to the others asynchronously. It cuts write latency and survives region loss, in exchange for conflicts that must be handled. Examples include CouchDB, Cassandra multi-DC, Galera-like setups and DynamoDB global tables.

How it works

 Region EU (leader) <--async--> Region US (leader)
        ^                              ^
        +------------async------------+
                  Region AP (leader)

User in EU: write x=1 at EU leader, ack locally
User in US: write x=2 at US leader concurrently
Both replicate: conflict on x -> resolve

Conflict handling options:

  • Avoid: pin each record or tenant to a home leader
  • Last-write-wins: highest timestamp wins, simple but lossy
  • Merge: version vectors with application or CRDT merge
  • Custom handler: run business logic on conflict

Each change carries its origin leader id so a leader does not re-send changes it already applied.

Pitfalls

  • Last-write-wins with unsynchronized clocks discards valid updates. Use hybrid logical clocks or version vectors.
  • Auto-increment keys collide across leaders; use UUIDs or per-region ranges.
  • Cross-row constraints and secondary indexes can be violated by concurrent independent writes.
  • Triggers and cascading changes may replicate inconsistently.
  • Replication lag during partitions grows backlog; monitor conflict rate and queue depth.

Key takeaways

  • Multi-leader buys local writes at the cost of conflicts.
  • Prefer conflict avoidance through data placement; resolve the rest with explicit merge logic.
  • Do not rely on cross-region uniqueness or foreign key guarantees.

✓ When to Use

  • •Geo-distributed apps needing local writes
  • •Offline-capable clients that sync later, each acting like a leader
  • •Multi-datacenter active-active deployments

✗ When Not to Use

  • •Workloads with frequent conflicting writes to shared records
  • •Strict constraints like unique keys and foreign keys across regions
  • •Systems that can tolerate one write region

Pros

  • +Local write latency in each region
  • +Tolerates regional outages for writes
  • +Better write capacity distribution

Cons

  • −Conflict resolution complexity
  • −Weak guarantees across constraints and transactions
  • −Hard to reason about causality and ordering

Cost Profile

Infrastructure

Full database footprint per region plus cross-region bandwidth

Operational

High: conflict monitoring, topology management

Cognitive

High: conflict semantics

Failure Modes

  • Silent data loss from last-write-wins on skewed clocks

  • Replication loops or out-of-order delivery causing divergence

  • Uniqueness violations from concurrent inserts in different regions

Real-World Examples

Alternatives

    Related Patterns

    • replication
    • read-replica
    • leader-election

    Competency Domains

    data statedistribution communication