Data residency is a requirement that data be stored, and often processed, only in a named country or region, and it covers every copy: backups, replicas, logs, traces, search indexes, embeddings and the requests you send to a hosted model. It can come from a contract, a sector regulator or a customer’s policy. The GDPR, for example, does not require that data stay in the EU; its Chapter V restricts transfers of to third countries, meaning countries outside the European Economic Area, and to international organizations (the GDPR text on EUR-Lex).
In an FDE interview
In a design that keeps EU data in the EU and US data in the US, the weak answer deploys two stacks and ships logs to one region. A strong candidate lists every store and every processor in order and keeps the global control plane to a map from tenant to region, with no user emails or names in it. They pin or scrub third-party error tracking and analytics, keep disaster-recovery replicas inside the region, and treat a support engineer in the US opening an EU record as a transfer, not a read.
Residency promises are worded narrowly: Notion announced in a March 2026 blog post that, from May 2026, Enterprise customers in Japan and South Korea could keep their Notion data at rest in-region. Source 1Notion expands data residency to Japan and South KoreaPublisherNotionSource typecompany blog A promise about storage says nothing about where data is processed, logged or read by support staff, so when a customer says their data must be resident, ask which they mean: at rest, processed, or never accessed from outside the region.
The lesson Data, PII and compliance covers residency and transfers, and a planned EU and US residency design prompt will be the practice.