Data that is not allowed to leave the country changes the architecture

The architecture review was going fine until somebody from the audit side asked a plain question. Not where the database sat, that was already on the diagram, in the correct region, with the correct flag ticked in the cloud console. The question was where the backups went.

Nobody in the room knew. The database was a managed service, backups were part of the service, and the retention period was in the contract. It took most of a fortnight to get a written answer from the vendor. The answer turned out to be acceptable. The fortnight was the finding.

That is what a residency requirement actually asks of a system. Not which region you selected, but an inventory of every place a byte of customer data or anything derived from it comes to rest for longer than a moment, and a list of every human and every process that holds credentials to read it. There are two broad architectures on offer to a regulated buyer, and they answer that question in completely different ways. It is worth knowing which one you are being sold before the audit tells you.

A region is a placement setting, not a boundary

Choosing a region decides where the primary copy of the data lives. Nearly everything else in a running system is a separate decision, usually made by a different team, usually left at whatever the default was. None of it is sinister. All of it counts.

• Backups and disaster recovery Snapshots and cross-region replicas frequently land somewhere other than the primary, because that is the whole point of a DR copy.
• Write-ahead logs and change streams Replication logs and CDC topics carry full row images and are commonly routed through whichever streaming cluster the platform team already runs.
• Logs, metrics and traces Observability is nearly always centralised, because nobody wants a separate dashboard per region. Request logs contain identifiers, and error traces often contain payloads.
• Error tracking and crash reporting Exception reporters capture local variables by default. That is enormously useful in an incident and it means real records get shipped to a third party.
• Support and administration tooling Impersonation, the read-only admin console, the ticketing system where a screenshot of somebody's account gets pasted.
• Caches, queues and search indexes Derived copies that are easy to forget precisely because they are derived.
• The vendor's own analytics Product usage telemetry counts as data about your customers even when it does not contain their names.

Work through that list for any multi-tenant service and the answer is often still fine. Mature vendors run regional stacks and can tell you where each piece sits. The problem is that the list is the vendor's to answer, not yours, and it changes when they change a subprocessor. Your control is a contract clause and an annual attestation. If that is the level of assurance your regulator wants, this shape works and it is much cheaper than the alternative.

The other shape: the software goes to the data

The alternative is to deploy the platform inside the customer's own cloud account. The storage buckets, the compute, the network and the encryption keys all belong to the customer. The vendor ships software into that account and keeps a small control plane outside it that holds versions, health signals and licensing, and never holds rows.

This is the shape we build Antvia in, and the honest summary of the trade is that it makes the residency answer trivial and makes almost everything else harder. The boundary stops being a promise and becomes a fact you can see in your own cloud bill. In exchange, several things that were previously the vendor's private business become part of the design.

What that pulls into the design

A boundary you can only describe in a contract is a boundary somebody else maintains on your behalf.

The distinction, stated plainly

The real leak is copies, not regions

In practice, residency rarely fails at the infrastructure layer. It fails because an analyst exported a CSV to build a slide, because a BI tool cached an extract on a server nobody classified, because a notebook wrote a working table into a personal schema, or because a data science team copied a sample to a laptop and then to a machine learning service in a different country. Every one of those is a person doing their job with the tools they were given.

Which is why the governance has to sit on the query rather than on the export. If row filters, column masking and purpose restrictions are enforced by the engine that answers the query, they hold whether the request came from a dashboard, a notebook, a scheduled job or an agent. If they are configured in the BI tool, they hold for people who use the BI tool. Open table formats such as Iceberg help here for a related reason: the data stays in the customer's own object storage in a format several engines can read, so the copy that gets made for a new use case can be made in place rather than by moving files somewhere less governed.

Lineage stops being a documentation exercise at this point and becomes the audit answer. When somebody asks whether a particular field ever reached a particular report, the only credible reply is a traced path, not a recollection.

When deploying into the customer's account is the wrong answer

Often. If the customer has no platform team, you have just handed an operational burden to people who did not ask for one and cannot staff it. Upgrades will lag, sometimes by a year, which means a known bug you fixed in March is still live in their environment in December and you will be blamed for it anyway. Costs go up, because dedicated infrastructure per customer does not share anything. And a small vendor supporting thirty bespoke environments, each with slightly different network policy and IAM, will spend its engineering capacity on environment archaeology instead of on the product.

There is also a quieter failure. Deploying inside the customer's account is not compliance. It answers a residency question and it answers nothing about retention, consent, minimisation, or whether the data should have been collected. Teams that win the residency argument sometimes assume the rest came with it.

So the shape is worth its cost when the requirement is genuinely sovereignty rather than localisation, when the customer already runs a competent cloud platform, or when the data is such that the buyer's legal team will never sign off on it sitting in an account somebody else controls. Public sector, parts of banking and most clinical data sit there. A lot of other work does not, and telling a buyer that plainly is more useful than selling them the harder architecture.

The question worth asking a vendor

Ask them to draw every location where your data or anything derived from it comes to rest, including backups, logs, error payloads, caches, support tooling and subprocessors, and to name who can read each one. A vendor with a clean answer will produce it quickly, because they have needed it before. A vendor who has to go and find out has told you something useful too. Either way, that drawing is the thing your auditor is actually asking for, and it is better to have it before the review than a fortnight after it.