Multi-Region Databases and Geo-Replication

Geo-replication keeps copies of data in several geographic regions so users get low latency wherever they are, and the system survives the loss of an entire region. The hard part is that light takes tens to hundreds of milliseconds to cross continents, so every design chooses how much consistency to pay for in latency: single-leader setups keep one region authoritative, multi-leader setups let every region accept writes and resolve conflicts, and consensus-based setups make every write wait for a cross-region majority.

The physics

Any write that must be acknowledged by another continent before success inherits that delay. That's the cost the PACELC framing describes: even without a partition, you trade latency for consistency. See CAP and PACELC.

Replication topologies

Conflict resolution in multi-leader setups

If two regions update the same record during the same window, both writes succeed locally and conflict when they replicate. Options:

• Last-write-wins by timestamp: simple, loses one write, sensitive to clock skew.
• Avoid conflicts by design: home each record (each user, each tenant) in one region so only that region writes it.
• Merge with CRDTs for counters, sets and collaborative data. See CRDTs.
• Application-level resolution: keep both versions and resolve with domain rules or the user.

Invariants like "don't oversell the last seat" or "balance can't go negative" can't be enforced by two regions independently. Route those operations to one authoritative region or use cross-region consensus.

Reading your own writes across regions

A user updates their profile through a nearby region, then a request is served by another region whose replica hasn't caught up, and the old profile appears. Fixes include routing a user to their home region for a while after a write, tracking the replication position the user has seen and waiting until the replica reaches it, or reading from the leader for that user's own data. See consistency models.

Data residency and sovereignty

Laws and contracts may require some data, such as personal or financial records, to stay within a country or region. Geo-partitioning puts each record's authoritative copy (and sometimes all copies) in its required region, while shared, non-sensitive data replicates globally. Plan this into the data model; it's hard to retrofit.

Failover between regions

• Decide the RPO (how much recent data can be lost) and RTO (how fast service must return) per dataset. Asynchronous replication means a non-zero RPO. See disaster recovery.
• Automate failover, but guard against split brain: two regions both believing they're the leader after a partition. Use a consensus-based arbiter or fencing. See leader election.
• Practise regional failover regularly with game days. See chaos engineering.