Six weeks before launch, legal confirms that customer data for one market must be processed and stored in-country. The architecture is single-region in another jurisdiction. What do you do?

Establish exactly what the requirement covers

Before designing anything, get three things in writing from legal: which data is in scope — usually a defined category such as personal data of residents, not the whole system; what "processing" includes — storage certainly, and typically transit, backup and administrative access; and what exceptions exist, since some regimes permit transfer for specific purposes under specific mechanisms.

The scope determines whether this is a configuration change or a re-architecture, and the difference is very large. Scoping it to the actually regulated dataset rather than to the whole system is usually what makes a solution feasible.

Enumerate every route data leaves by

Selecting an in-country region for the primary database is the visible step and not the whole job. Data leaves by:

• Backups and snapshots, often cross-region replicated by default.
• The disaster recovery region, usually chosen for cost or capacity.
• Logs and telemetry, which routinely contain personal data and go to a central observability platform elsewhere.
• Support and administrative access — an engineer in another jurisdiction viewing production data is a transfer.
• Third parties whose processing location differs from where they are incorporated, including sub-processors.
• CDN and edge caches holding personalised responses.

Each is a separate decision and each has to be closed.

Options at six weeks

Full in-country stack — application, data, logging, backup, recovery, and in-jurisdiction operational access. Correct, and unlikely in six weeks unless the architecture was already multi-region and parameterised.

Data-tier only, with the in-scope dataset stored in-country and stateless compute elsewhere. Whether this satisfies the requirement depends entirely on whether compute touching the data constitutes processing — which is a legal question, not an architectural preference, and it is the one to ask first because the answer changes the plan.

Launch without that market, adding it when the in-country deployment is ready. This is frequently the right answer and it is the one nobody wants to propose. It is worth costing honestly: the delayed revenue against the cost of a rushed deployment that may not actually comply.

Minimise at the border — pseudonymise or aggregate before anything leaves, so the data crossing is not in scope. Sometimes reduces the problem substantially and is worth assessing before assuming the full stack is required.

The recommendation and how to frame it

Present the options with their compliance confidence, cost and timeline, and make the confidence level explicit. A design that "probably complies" is not a design; the question of whether stateless compute constitutes processing must be answered by legal before it is built on.

If the honest answer is that full compliance takes twelve weeks, say so with the evidence. Launching non-compliantly into a regulated market is a materially worse outcome than a delayed launch, and it is the architect's job to make that trade visible rather than to absorb it.

Afterwards

This is a governance finding as much as a technical one. A requirement of this weight surfacing six weeks before launch means obligation mapping did not happen early. The remediation is to make regulatory constraints an input to design alongside the non-functional requirements, for the next project — which is the durable fix and the one that will be forgotten unless it is written down now.