A product must keep certain customers' data within specific jurisdictions. What are the architectural options, and which parts are hardest?

Establish what is actually required

"Data residency" covers several distinct obligations and conflating them produces either over-engineering or non-compliance:

• Storage residency: data at rest must be within the jurisdiction.
• Processing residency: computation must occur there too.
• Access control: personnel outside the jurisdiction must not be able to access it — frequently the hardest requirement and the most often overlooked, because it constrains support and operations rather than infrastructure.
• Sovereignty: the operator must not be subject to foreign legal compulsion, which restricts provider choice and sometimes requires local operation.

Determine which applies, per data category, since the answer is rarely "everything."

The options

Regional deployment per jurisdiction — a complete stack per region, with customers routed to theirs. Strong isolation, straightforward to explain to a regulator, and expensive: every regional deployment is another environment to operate, deploy to and monitor. Global features — cross-region search, aggregate reporting, a single admin view — become genuinely difficult.

Row-level residency in a geo-partitioned database — one logical system with rows pinned to regions. Operationally far simpler, and it requires the regulator to accept a logical rather than physical separation, which varies by jurisdiction and must be confirmed rather than assumed.

Split architecture — regulated data local, everything else global. The most economical approach and the one requiring the most care, because the boundary must be exactly right and the pressure to place things on the convenient side is continuous.

Local data with global metadata, where identifiers and non-personal attributes are global and personal data stays local — which enables global search and routing without moving the regulated content.

The parts that are hardest

• Support and operations access. An engineer debugging an incident must not access data they may not see — which requires per-jurisdiction operational tooling and staffing, or an access model enforced at the platform level. This is where residency programmes most often fail in practice.
• Backups and disaster recovery. A backup is a copy, and a DR region in another jurisdiction violates the requirement — so DR must be within the jurisdiction, which may mean a second local region or a degraded recovery posture.
• Telemetry. Logs and traces contain personal data by default, and the observability stack is usually global — this is a very common and entirely inadvertent violation.
• Third parties. Every processor — email, analytics, error tracking, support tooling, payment providers — must comply, and their sub-processors too.
• Aggregate analytics, which needs data from everywhere. Local aggregation with only aggregates crossing the boundary is the standard resolution, and it constrains what analysis is possible.
• Machine learning, where training on global data is precisely what the requirement prevents. Federated approaches or per-region models are the answers, both with real cost.

The design principle

Partition by residency from the beginning, even before it is required. Ensure every table that could hold regulated data carries a jurisdiction attribute, and that the routing layer can direct a request by it.

Retrofitting residency into a system that assumed global data is among the more expensive migrations in enterprise software — the assumption is embedded in schemas, in caches, in indexes, in every pipeline and in the operations model — while carrying an unused jurisdiction column costs almost nothing.