A globally distributed application routes users to nearby regions but holds state that cannot safely be duplicated. Which components should be regional, which globally replicated, and which operations should stop during a regional outage?

The three categories

Regional (independent per region): stateless application servers, caches, edge routing, session handling. These can exist everywhere and their loss in one region costs only that region's capacity.

Globally replicated, read-anywhere, write-somewhere: reference data, configuration, catalogues, user profiles. A single-writer primary with read replicas everywhere gives local read latency and a simple consistency story. Writes are rare and can pay the cross-region round trip.

Single-region, not replicated for writes: anything with an invariant that cannot survive concurrent modification — balances, inventory, sequence generation, anything a regulator will audit. These should be pinned to one region per entity, not one region globally: partition by customer or account so different entities live in different regions and the loss of one region affects a subset rather than everyone.

What stops during a regional outage

The honest answer is that write operations for entities homed in the failed region stop, and that is correct rather than a failure of design. The alternatives are worse: automatic failover of a strongly-consistent writer risks two writers and a split ledger, and the cost of reconciling that exceeds the cost of the outage.

What continues: all reads (from replicas elsewhere), all operations on entities homed elsewhere, and any degraded mode you deliberately built — queueing writes for later application, if the domain tolerates it.

The decision that must be explicit

Which components fail over automatically and which require a human decision. Stateless tiers fail over automatically. A strongly consistent primary should fail over only with a quorum-based mechanism that guarantees the old primary cannot accept writes, or with a human confirming the region is genuinely gone.

"Automatic failover for everything" is the default that produces split-brain, and in a financial system a split ledger is far more expensive than an hour of unavailability.

The trap

Global write replication is frequently proposed to reduce write latency. It introduces concurrent writes to the same entity from multiple regions, which requires conflict resolution, which for anything with an invariant means either losing writes or inventing a merge semantics nobody can reason about. The evidence required to justify it is that write latency is genuinely a product problem — not that it would be nice.