Active-active and home regions

In active-active, every region serves live traffic. Users near each region get low latency, and failover becomes "stop sending traffic to the broken region" instead of "wake up a cold standby". That raises the hard question: where do writes go? The most common answer is a home region for each user or tenant. The home region owns that user's writes, so two regions never fight over the same record.

The big idea

Each region is the primary for its own slice of the data. A bank with branches works the same way: each branch holds its own customers' accounts, and each account lives in one place.

Travelers still write to their home region and pay the round trip. Interactions across home regions need explicit cross-region calls or asynchronous replication.

Walking through it

The home-region design has useful side effects:

• Writes stay local and strongly consistent within a region, with no cross-region conflicts.
• Data residency comes almost for free. European data lives and is written in Europe.
• On a regional failure, the affected users' data fails over to a replica in another region. For that slice, the design is active-passive.
• Routing must find the home region. The edge or first service looks up the home region from a token claim or a small, globally replicated directory, then forwards the request. The nearest region is not always the right one.

Store the home region on the user or tenant record, include it in auth tokens, and change it only through a planned migration: copy the data, catch up with change data capture, flip the directory. That is the same sequence used for moving a tenant.

Multi-writer data

The alternative lets any region accept writes for any record, with replication in every direction. Latency is low everywhere, but concurrent updates need conflict resolution. Last-writer-wins keeps one update and silently drops the other. Application-level merges and CRDTs are the other options.

DynamoDB global tables, in their original mode, work this way. Replication typically takes about a second, and conflicts resolve by last writer wins. That suits a shopping cart or user preferences. It is wrong for an account balance. The rule of thumb: multi-writer replication fits data where a lost concurrent update is tolerable or can be merged. Anything with invariants, such as balances, inventory or uniqueness, needs a single writer per record.

Capacity for active-active

To survive losing one of N regions, the remaining regions must absorb its traffic:

each region must handle 1 / (N - 1) of total traffic
total provisioned     N / (N - 1) x peak

2 regions: each sized for 100% -> 200% total (100% overhead)
3 regions: each sized for 50%  -> 150% total (50% overhead)
4 regions: each sized for 33%  -> 133% total (33% overhead)

More regions give the same protection for less overhead, which is one reason large companies run three or more. The capacity must already be in place when a region fails. It can't be scaled up under stress.

Common mistakes

• Using multi-writer replication for balances or uniqueness. Last-writer-wins silently drops updates, which can mean lost money or duplicate accounts.
• Sizing each region for its own average traffic. Each region must carry its share of peak plus the failed region's share.
• Calling across regions in the request path. A synchronous call from us-east to eu-west adds about 80 ms and couples the regions' availability.

Check yourself

1. Three regions, and you must survive losing one. How much total capacity do you provision, relative to peak?

   Each region handles 1/(3 − 1), or half, of peak, so the total is 3/2, which is 150% of peak.

2. Why is last-writer-wins unsafe for an account balance?

   It silently drops one of two concurrent updates, so a deposit or a withdrawal can vanish.

Key takeaways

• Active-active works best when each user or tenant has a home region that owns their writes.
• Home regions avoid write conflicts and make residency nearly free.
• Multi-writer replication needs conflict resolution, and it suits only mergeable data.
• To survive losing one of N regions, provision N ÷ (N − 1) of peak.

Further learning

Next: globally consistent databases, for the data that must be consistent across every region.