ADR-006: One region per client, set at onboarding
By Rafael Duarte · created 7 Nov 2022, 10:00 UTC · last updated 20 Jan 2025, 14:30 UTC · version 4
adrregionsdata-residency
Status: accepted · Date: 7 November 2022 · Decided by: Rafael Duarte, Mira Holm, Quinn Maas
Context
All our clients are in Frankfurt today. UK prospects ask, in almost every security questionnaire, whether their data can stay in the UK, and two said they wouldn't sign without it. Food customers in the EU ask the reverse: that nothing leaves the EU. We need a way to promise a place, and to keep the promise without relying on people remembering.
Options:
- One stack, data tagged by country, with storage per country.
- A complete stack per region, each client in exactly one.
- Wait until a deal depends on it.
Decision
A complete stack per region: identity-service, notifier, database, queue, file and backup storage, and keys. Each client (our code's word for a customer) is placed in one region when it is onboarded. Its data and its backups stay in that region. Nothing is copied between regions. We start with the EU and add a region when a contract needs one.
A small edge table maps each client's sign-in address to its region. It holds no personal data.
Consequences
- Each new region is a full set of infrastructure to run, monitor, back up and patch.
- A client can't move region without a migration project. Choosing the region at onboarding matters.
- Code must never assume a region (see Coding standards).
- Third parties we send data to (mail, SMS) need checking per region; this ADR doesn't solve that.
- Restores happen in the client's region only, which limits disaster recovery to the region's own availability zones.
Updates
- 3 June 2024: UK region approved for 2025.
- 20 January 2025: UK region (London) live. Northgate and Brakeline moved there over two weekends with a one-off migration.