Data Residency

Residency requirements arrive from several directions — sector regulation, national law, public sector procurement, and increasingly customer contracts — and they reshape architecture more than almost any other non-functional requirement.

The first question to force into the open is what exactly is constrained, because the answers differ enormously in cost. Storage at rest in region is the easiest. Processing in region rules out a global control plane touching the data. Access from within the region excludes support engineers elsewhere, which is an operating model change rather than a technical one. And metadata is the clause that catches people out, since backups, logs, telemetry, search indexes and disaster recovery copies are data too and routinely default to a different region.

The architectural consequences compound. Multi-region becomes mandatory rather than a reliability choice. Global aggregation must happen on data that cannot leave, which pushes towards computing aggregates locally and combining only the results. Shared services — identity, configuration, observability — need either regional deployments or a demonstrable guarantee that no regulated data flows through them. Disaster recovery must fail over to a location that is still compliant, which may mean a second in-region site rather than the natural alternative.

The costly mistake is treating residency as a deployment parameter discovered late. It is a partitioning decision that touches identity, routing, data model and operations, and retrofitting it into a globally replicated system is close to a rebuild.