Data Residency and Regional Deployments

Keeping data in the right country

Some customers and regulations require that certain data is stored, and sometimes processed, inside a particular country or region. Multi-tenant products meet this with regional cells: complete copies of the application plane (services, databases, storage, queues) deployed in each supported region, with each tenant pinned to one region in the catalogue at sign-up. Requests are routed to the tenant's region, often via a regional hostname or a global router that reads the catalogue. The tricky part is everything global: the login page, the tenant catalogue, billing, support tools, logs, analytics and third-party services. Keep regulated data out of them by storing only what routing needs globally, scrubbing personal data from logs, and keeping backups and replicas inside the same region. Moving a tenant between regions is a tenant migration with legal sign-off, so offer region choice up front.

Region pinning in configuration

An illustrative YAML catalogue entry and region map. Backups and replicas stay inside the tenant's region.

regions:
  in-west:
    api: https://in.api.example-saas.com
    backup_region: in-south     # still inside India
  eu-central:
    api: https://eu.api.example-saas.com
    backup_region: eu-west

tenants:
  acme:
    region: in-west
    plan: pro
  bergmann-gmbh:
    region: eu-central
    plan: enterprise

Logs are data too

A perfectly regional database is undermined if request logs with customer names and emails ship to a central logging cluster in another country. Treat logs, traces and error reports as part of residency scope.

Quick check: A tenant is pinned to an India region. Which design choice most likely violates its residency requirement?

• Serving its API from the India cell
• Storing its backups in another India region
• Shipping its full request logs, including personal data, to a logging cluster in another continent
• Keeping only its tenant id and region in the global catalogue