Globally-Consistent Multi-Region Data

Physics sets the rules

Once your data lives on more than one continent, physics sets the rules. Light in fiber crosses the Atlantic in about 40ms one way, so a New York to Frankfurt round trip is ~80ms and a synchronous write that waits for a quorum spanning both regions costs 100+ ms before you add any processing. The whole design is about deciding, per piece of data, whether that latency is worth paying for correctness.

CAP and PACELC in practice

CAP says under a network partition you choose consistency or availability. PACELC adds the part interviewers actually want: Else (no partition), you still trade Latency against Consistency. A globally strong-consistent write is slow because it must reach a cross-region quorum; a fast local write is only locally consistent. There is no configuration that gives strong consistency and low latency everywhere for free. State this out loud.

How you still get strong consistency

Replicate each data shard across regions with a consensus protocol (Paxos or Raft): a write commits when a majority of replicas acknowledge. Place replicas so the quorum is reachable quickly. Google Spanner adds TrueTime, an API that returns time as an interval [earliest, latest] bounded by GPS and atomic clocks (uncertainty typically a few ms). To commit at timestamp T, Spanner waits out the uncertainty (commit-wait) so that no later reader can observe an earlier timestamp. This gives external consistency: if transaction A commits before B starts, A's timestamp is smaller, globally. Without special clocks you approximate ordering with Hybrid Logical Clocks (HLC), which combine physical time with a logical counter to preserve causality (CockroachDB, YugabyteDB use this).

Data placement is the real lever

You do not need every row to be globally consistent. Geo-partition: pin each row to a home region near its owner. A European user's account lives with its leader in Frankfurt, so their reads and writes are local (single-region quorum, single-digit ms) and only rarely touch another continent. US users' rows are led from us-east. You pay cross-region latency only for genuinely cross-region operations. Add follower reads (read a nearby replica at a slightly stale timestamp) and read leases (a leader holds a lease so it can serve strongly consistent reads without a quorum round trip) to make local reads cheap.

EU user  -> leader in Frankfurt   -> local quorum (EU replicas) ~ single-digit ms
US user  -> leader in us-east     -> local quorum (US replicas) ~ single-digit ms
cross-region txn (EU pays US) -> two-region coordination ~ 100+ ms  (rare by design)

Active-active, and the consistency spectrum

Active-passive keeps one write region and fails over (simple, but the standby's capacity sits idle and failover has an RTO). Active-active accepts writes in multiple regions and must resolve conflicts: Last-Write-Wins (simple, silently loses data on concurrent writes), CRDTs (conflict-free types that merge deterministically, great for counters, sets, presence), or application merge. For money you generally avoid multi-writer conflict resolution entirely and route each account's writes to its single home leader.

Pick a consistency level per workload: strong (balances, must be exact), bounded-staleness (read at most N seconds old, fine for a profile), causal (you always see your own writes and their causes), eventual (a like count). Track RTO and RPO for failover, and data residency (GDPR) which may force certain rows to physically stay in-region.

Interview nuance: for a balance, the correctness requirement is no double-spend, which is a single-key serializable constraint. You get it cheaply by homing each account in one region so its writes serialize through one leader, then using Spanner-style TrueTime or a Raft leader for ordering. You do not need global multi-writer consensus for every action, only correct ordering per account.

Recap: cross-region synchronous writes cost 100+ ms because of the speed of light, so use consensus plus TrueTime/HLC for correct ordering, geo-partition rows to their home region for local reads and writes, add follower reads and leases, and choose a consistency level per workload instead of paying for global strong consistency everywhere.