MODULE 6 · LESSON 3
Free — no login requiredSign in to track progress, save quiz attempts and enrol in the full course.
Sign in to track progress / enrolArchitecting for Multiple Jurisdictions
The design goal
Stated once, and everything else follows from it:
Where data is processed should be a configuration value, not an architectural assumption.
A product that can be pointed at a different region by changing settings can enter a new market, satisfy a new customer requirement, or absorb a change in transfer law as a deployment task. A product where the region is baked into a hundred assumptions cannot, and rewriting it under commercial pressure is where teams lose quarters.
This is cheap to do at the start and expensive to retrofit — the same shape as the pricing lesson in module 4.
What must be regional, and what need not be
Not everything needs to move, and treating it as all-or-nothing makes the problem look harder than it is.
The fourth row is the one that catches teams, and it deserves its own treatment.
The leaks that defeat a careful design
A residency commitment fails at the edges, not in the middle. The main inference path is usually handled correctly; these are what get missed:
Error tracking and observability. An exception handler capturing the full request — including the customer's document — and sending it to a monitoring service in another country. Extremely common, invisible until an audit, and it defeats the entire design.
Prompt and response logging for debugging. Retained to investigate quality issues, stored centrally, often for longer than the customer data itself.
Support tooling. A support engineer viewing a customer's content through an admin interface served from elsewhere, or pasting it into a ticket.
Backups. Replicated to a region chosen for durability rather than for residency.
Evaluation datasets. Real customer cases collected into your evaluation suite — as module 3 recommends — and then stored with your engineering assets rather than under the residency rules the source data was subject to. This is a genuine tension between good practice and compliance and needs an explicit answer, usually anonymisation or synthetic substitution.
Fine-tuning datasets. The same problem with higher stakes, since the data is not only stored but absorbed.
Caching layers. A cache holding generated responses in a global service.
The practical instrument: trace one real customer request end to end and write down every system it touches, including failure paths. An afternoon, and it finds most of these.
One flexible deployment, or several regional ones?
Two architectures, with a real trade-off:
A single deployment with regional routing. One codebase, one release, routing per customer or per tenant to the correct regional endpoints and stores. Simpler to maintain and to keep consistent. Requires disciplined data handling so that nothing crosses regions inadvertently, and it makes strong sovereignty claims harder because the control plane is shared.
Separate regional deployments. A full instance per region. Stronger separation and a much easier story in an enterprise or public-sector review. Costs more, and versions drift unless releases are coordinated — which in practice they will, so plan for it.
The pragmatic path for most products: start with a single flexible deployment and the discipline to keep regional data regional, and move to separate deployments only for markets whose requirements genuinely demand it. Building four regional deployments before you have customers in four regions is a way to multiply your operational burden ahead of any revenue.
A composite drawn from a very common sequence.
A product is built, sensibly and quickly, on a single provider in a single region. It works. The company sells to mid-market customers who do not ask hard questions.
Then a large European customer arrives with a requirement that data be processed and stored in the EU. The deal is worth more than the previous ten combined.
The team's assessment finds:
- Inference: straightforward. The provider offers an EU endpoint; it is a configuration change.
- Vector index: harder. A single global index with tenant identifiers, so EU customer embeddings sit alongside everyone else's and cannot simply be moved without a migration and a re-index.
- Document storage: the bucket is regional but backups replicate to another continent for durability.
- Logging: the error tracker captures full request payloads. This is the one that stops the deal on its own.
- Evaluation set: contains real customer documents, stored with engineering assets, some of which came from EU customers who never consented to that use.
- Support tooling: admin views proxy content through a central service.
None of these is individually difficult. Together they were two quarters of work, done under deal pressure, competing with the roadmap, and touching the parts of the system nobody wanted to change.
The version of this work that costs a fortnight is done at the beginning: tenant-partitioned storage from the start, an index per region rather than one global index, payload-free logging by default with an explicit opt-in for debugging, and an evaluation set built from anonymised or synthetic cases.
None of those decisions slows an early-stage product meaningfully. All of them are painful to introduce later. The general rule for this module: the residency-ready architecture and the ordinary architecture differ by a handful of early choices, and the cost of not making them is paid at exactly the moment a large customer arrives.
Which component most commonly defeats an otherwise careful data residency design?
The design goal
Click to flipWhere data is processed should be a configuration value, not an architectural assumption — cheap at the start, expensive to retrofit.
Click to flip backMake processing region a configuration value rather than an assumption, because that single property turns a market-entry or transfer-law change from a rebuild into a deployment. Know which components must be regional and which need not — then hunt the leaks at the edges, especially error tracking that captures full payloads, backups replicated for durability, and evaluation sets built from real customer data. Start with one flexible deployment and split only where a market genuinely demands it.