Multi-region and data residency
Users on the other side of the world, laws about where data may live, and one very expensive round trip.
What problem does multi-region solve?
One region means everyone far away pays 150 ms per round trip, and a regional outage is a total outage. Both are real reasons to run in more than one place.
But going multi-region does not just copy your system. It changes what is possible, because the speed of light now sits between your machines, and in some cases the law does too.
What multi-region costs you
Every concept in here states a cost. A technique with no price is a technique you have not understood yet — and naming the cost out loud is most of what separates a senior answer from a junior one.
When to reach for multi-region, and when not to
Use it when
- Users are spread worldwide and latency is part of the product.
- You have an availability target that a single region cannot meet.
- The law requires certain data to stay inside certain borders.
- A single region is at capacity, which is rare and worth checking.
Do not, when
- You have not filled one region. Most systems never need this, and it makes every future feature slower to build.
- Uptime is the goal and the real cause of your outages is deploys. Multi-region does nothing about that.
- The data is inherently global and contested. Two regions cannot both authoritatively sell the same seat.
How multi-region actually works
- —All writes travel to the home region. Reads are served locally and are fast.
- —Simple. No write conflicts, because there is only one writer.
- —A user far from the home region pays the full round trip on every write.
- —Losing the home region means writes stop until you promote another one.
- —Right for: most products, most of the time.
- —Writes are fast everywhere, because they are local.
- —The same record can now be written in two places at once. You own that conflict.
- —Needs a merge rule, or data partitioned so a record only ever belongs to one region.
- —Survives losing a region without a promotion step.
- —Right for: partitionable data, such as a user's own data or a region's own orders.
Start by separating the two reasons, because they lead to different designs. Latency is solved by putting reads close to users, and a CDN plus read replicas gets you most of it without touching your write path. Availability is solved by being able to take writes somewhere else, and that is the expensive part. Say which one you are buying.
The pattern that works is home region per record. Pick a partitioning key that matches how the data is used (usually the user, the tenant, or the market) and give each one a home region where its writes happen. A user in Europe writes to Europe. Their data is replicated elsewhere for reading and for disaster recovery, but only one region ever accepts writes for them. You get local writes for almost everyone, no conflicts by construction, and a clean story for failover. The cost is routing: something has to know where each record lives, and a user who travels pays the round trip until you move them.
What cannot be partitioned is the interesting part, and most systems have some. A global unique username. Inventory sold worldwide. A shared balance. For those, accept one authoritative region and pay the round trip, or push the decision behind a queue where the ordering is done in one place. The mistake is pretending these can be regionally owned; the result is selling the same item twice, one sale per region.
Data residency is a legal constraint, not a technical preference, and it changes the design more than latency does. The GDPR restricts moving personal data out of the EU, and some national laws require certain data to stay inside the country. That means your partitioning key has to include the region, and backups and logs have to respect it too. People forget the logs, because personal data ends up in them without anyone deciding to put it there. And "just replicate everything everywhere" stops being an option. If a question mentions users in the EU, say this out loud.
Failover between regions is not the same as failover between machines. The data in the failed region may be seconds behind, so promoting another region means accepting the loss of whatever had not replicated, and you should say how much that is. The decision also needs to be made by something outside both regions, or a network split leaves both believing they should be primary. And failing back afterwards is harder than failing over, because the recovered region now has writes that the promoted one never saw.
Two operational things that separate people who have done this. Deploys go one region at a time, so a bad release hits a fraction of users and you can stop. And a region needs to be able to run at higher load, because when one fails, its traffic goes to the others. Two regions at 60% capacity each cannot absorb one failing.
- Going multi-region for uptime when deploys are what actually causes your outages.
- Claiming multi-region writes without saying how conflicts are handled or avoided.
- Forgetting that a surviving region has to absorb the failed one's traffic.
- Treating data residency as a detail. It constrains the design more than latency does.
The multi-region follow-up an interviewer will ask
"You have users in the US and Europe. Where does the database live?"
My first question back is what kind of data, because the answer differs. For data that belongs to one user (their profile, their orders, their messages), I would give each user a home region based on where they signed up, write there, and replicate elsewhere for reads and disaster recovery. A European user gets a local write, no cross-Atlantic hop, and no conflict is possible because only one region ever writes their row. For data that is global and contested, such as a unique username or worldwide inventory, I would keep a single authoritative region and accept that some users pay 80 to 100 milliseconds on those specific operations, because being right matters more than being fast on a rare action. The costs I would name: a routing layer that knows where each user lives, and a real migration story for the person who moves from New York to Berlin. And if this is European personal data I would raise residency as a constraint before latency, because that decides whether replicating to the US is even allowed. It applies to backups and logs too, which is the part people miss.
Your turn
Why does going multi-region not automatically improve availability, and what usually causes your outages instead?
Learn it from the source
This page gets you interview-ready. These take you to where the idea is actually specified or measured — read them when you want the real depth.
- CockroachDB — Architecture Overview ↗How a database spanning regions handles the latency you cannot remove.