# Data Residency and Regional Deployments — Multi-Tenant SaaS Architecture

Source: https://www.skillbyai.com/en/multi-tenant-saas/mt-data-residency

> Pin tenants to regions to satisfy data residency requirements, and keep the global control plane from leaking regulated data.

## 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.

```yaml
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.

**Quiz:** 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
- [x] 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

*Answer:* Shipping its full request logs, including personal data, to a logging cluster in another continent. Logs with personal data are regulated data. Sending them abroad breaks residency even if the primary database stays in India.