In-Country Processing

Selecting a region for the primary database is the easy and frequently the only step taken. Data leaves by many other routes, and each is a residency question in its own right.

The ones that are missed, roughly in order of frequency: backups and snapshots replicated cross-region by default; the disaster recovery region, which is often chosen for cost or capacity rather than jurisdiction; logs and telemetry, which regularly contain personal data and are shipped to a central observability platform in another country; support access, where an engineer in another jurisdiction viewing production data is a transfer; third-party services whose own processing location differs from where they are incorporated; and CDN or edge caches holding personalised responses.

The consequence of the requirement is architectural rather than configurational. A genuinely in-country deployment means a full stack per jurisdiction — application, data, logging, backup, recovery — which multiplies operational cost and makes cross-region features such as a global user directory considerably harder.

The design decision worth making early is which data is genuinely subject to the requirement, because scoping it to the actual regulated dataset rather than to the whole system is usually the difference between a manageable design and an unaffordable one.