When the Data Is Not Allowed to Leave

The naive reading is that residency means putting a database in the right country. If that were all, it would be a deployment ticket. What makes it an architectural constraint is that every copy counts, and a running system makes far more copies than its architecture diagram shows.

The replica is obvious. The backup is usually remembered. After that the list gets uncomfortable: the read replica someone added for a dashboard, the search index, the analytics warehouse, the CDN cache, the message broker retaining a topic for seven days, the distributed trace carrying a request body, the application log line that included the payload for debugging, the error tracker with a serialised object attached, the machine-learning feature store, the exported CSV in an object bucket, and the third-party service the request was forwarded to.

So the useful formulation is not "where does the data live" but "enumerate every place a copy of this record can come to rest, and prove each one is inside the boundary." That enumeration is the actual work, it cuts across every team, and it is the reason residency cannot be retrofitted cheaply.

This is the part that surprises architects, and it is why this lesson sits in a distributed systems module rather than in a compliance appendix.

It forbids a global quorum. A five-node consensus group spread across Frankfurt, Dublin, Virginia and Singapore is a design that puts a copy of every committed record in all four places — that is what replication *is*. For residency-bound data, that group cannot exist. What you can have is a per-jurisdiction consensus group: five nodes inside the EU, across EU availability zones and EU regions. Which means the availability of that data is bounded by the availability of that jurisdiction’s infrastructure, and a design that assumed global quorum resilience quietly loses a failure domain.

It forbids a hash-partitioned global keyspace. Consistent hashing spreads keys across the ring by hash, which is precisely a scheme for placing data without regard to geography. For residency-bound data the partitioning key must be, or must be prefixed by, the jurisdiction — which means you get [[range-partitioning]] semantics whether you wanted them or not, with their [[hot-partitions]] behaviour, their rebalancing characteristics, and a partition count set by the map rather than by your load.

It forbids a global secondary index. An index over a field is a copy of that field placed wherever the index lives. A global uniqueness index over email addresses across jurisdictions is exactly the thing residency prohibits — and it is also, awkwardly, exactly the thing [[distributed-uniqueness]] needs. Reconciling those two is real design work, usually resolved by indexing a salted hash rather than the value, and accepting that even that may be in scope.

It forbids follow-the-sun operations for some data. An engineer on call in Singapore may not be permitted to query an EU production database, which turns [[distributed-debugging]] into a genuine problem: the person awake cannot see the data. The answer is that correlation ids, structured metadata and aggregate metrics must be sufficient to diagnose most incidents without payloads — a discipline worth having anyway.

Faced with a system that needs both global operations and jurisdiction-pinned data, the design that most often survives contact with reality is to split each record in two.

A globally replicable stub holds what the rest of the system genuinely needs everywhere: an opaque identifier, the owning jurisdiction, a status, timestamps, and nothing else. A jurisdiction-pinned payload holds everything that is residency-bound and never leaves. Global operations — routing, listing, aggregate counting, authorization checks — run against stubs. Anything needing the payload executes inside the owning jurisdiction and returns a result rather than the data.

This composes cleanly with [[multi-region-write-models]]’s partitioned ownership: the stub *is* the ownership directory, so a design that already homes data per tenant is most of the way there. It also makes the residency boundary auditable, because there is one table whose contents you must defend rather than a diffuse property of the whole schema.

Two honest complications. First, the stub is not automatically out of scope: an identifier that can be correlated back to a person may itself be regulated, and "we only replicated the user id" is not a defence anyone should rely on without asking. Second, the two-part read is a real cost — a global list view now shows stub data and must fetch payloads per jurisdiction, which is a scatter-gather with [[fan-out-tail-latency]] behaviour, and is usually the moment somebody proposes "just cache the payloads centrally".

The words are used interchangeably in conversation and they impose different designs, so it is worth separating them before a design review rather than during one.

Residency is about where data is stored. It permits processing elsewhere in some regimes and not in others, and it is satisfiable with careful placement. Sovereignty adds a claim about which government can compel access, which is a statement about the *operator* as much as the location — the same rack under a different corporate parent may satisfy one and not the other, and no amount of topology fixes it. Localisation is the strictest: the data must be stored and processed in-country, sometimes on infrastructure operated by a domestic entity, which can rule out your cloud provider entirely and force a genuinely separate deployment.

The design consequence: residency can usually be met by a cell per jurisdiction inside one provider. Sovereignty may require a different provider or a sovereign-cloud offering for one cell. Localisation frequently requires a fully independent stack, at which point the honest architecture is separate instances of the product that share code and share nothing else — no cross-instance replication, no global control plane holding regulated data, and a release process that can deploy to an environment your team cannot log into.

That last shape is unglamorous and is what most mature multi-jurisdiction products converge on. It is worth reaching it deliberately rather than by a series of exceptions.

Residency multiplies operational surface by the number of jurisdictions. Every cell needs its own deployment, its own capacity planning, its own on-call visibility, its own backup verification and its own upgrade path — and they will drift, in the same way an unexercised standby drifts. A four-jurisdiction system is four systems that happen to share a repository.

It also removes a failure domain you may have been relying on. Data pinned to the EU cannot be failed over to Virginia, so its disaster recovery story must be satisfied entirely with EU infrastructure. That is achievable — multiple EU regions exist — but it must be designed for, and it is a common gap in systems where residency was added after the DR plan.

And it changes the cost profile. Small jurisdictions get cells that are far below efficient scale, so per-customer infrastructure cost varies by an order of magnitude across the fleet. That is a business fact, not a technical one, and it is worth surfacing early because it determines whether serving a given market is viable at all.