Data Residency, Regions and Cells
By the Syncfusion DevTutorials team · Last updated
Keep each tenant's data in the regions its contract allows: home cells, a tenant directory for routing, every copy kept in-region, and a tenant moved between cells with no data loss.
The Contract Says "EU Only"
Fabrikam EU signed with Northwind on one condition: its data is stored and processed only in the European Union. Its regulator can ask where every copy of the data has been, and "mostly in Frankfurt" is not an answer.
Meanwhile Northwind is growing. One database cluster per region will not hold forever, and a single bad deploy should not take down every customer at once. So Northwind splits the system into cells: complete, independent copies of the stack, each serving a group of tenants in one region.
The main idea: give every tenant a home cell in a region its contract allows, route each request there through a small global directory, keep every copy of the tenant's data (backups, logs, search) in that region, and move tenants between cells with a copy, a stream of changes and a short read-only switch.
TL;DR
- Data residency means every copy: database, backups, logs, search indexes, caches, analytics exports, and the servers that process requests.
- A cell is a full, independent stack (app, database, queues, storage) for a group of tenants. Cells limit the blast radius and let you grow by adding cells.
- A small global directory maps tenant → home cell. The router looks it up for every request.
- Keep backups, logs and indexes in the cell's region. Only aggregated metrics leave.
- Move a tenant with: stream changes, copy a snapshot, read-only for minutes, catch up, switch, verify, then delete the old copy.
A Real-World Example
A SaaS company promised European customers EU-only hosting and built a Frankfurt region. An audit found customer names in US-hosted error-tracking logs, US backups of the Frankfurt database, and support staff reading European tickets through a US admin tool. Every one was a separate system that nobody had thought of as "storing data". The fix took six months.
What You Will Learn
- What a cell is, and why SaaS products use them.
- How a request finds its tenant's home cell.
- Why residency covers every copy of the data.
- How to move a tenant between cells with no data loss.
Cells: Many Small Copies of the System
The router and the tenant directory are global and hold almost nothing. Everything with customer data lives inside one cell in one region.
In Lesson 3, Contoso got a cell of its own to stop it slowing others down. Here the same idea is used for every tenant: cells of a fixed, tested size. When a cell is full, you add a new one, rather than making one database ever bigger.
A cell should not call another cell. If cells talk to each other, a failure in one spreads to the next, and the main benefit of cells is gone. Shared services (billing, the directory, sign-in discovery) should be small, simple and very well protected.
Routing to the Home Cell
The directory is small (one row per tenant) and read on every request, so cache it at the router, with a short expiry so moves take effect quickly.
Residency Means Every Copy
Support tools, analytics exports, error trackers and AI features are the usual leaks: they were built to look at everything in one place. List every system that receives customer data, and for each one say which region it runs in. Make that list part of the contract review.
Moving a Tenant Between Cells
Tenants move: a cell is full, a customer changes region, or a growing tenant needs a cell of its own. The move must lose nothing and stop the customer only briefly.
Try It: Residency and a Cell Move for Fabrikam EU
- Start with the defaults. Which of Fabrikam's data ends up in the US?
- Fix each row. Which change also helps other EU tenants?
- Clear the move plan and build one step by step. Try a plan without streaming changes first. How many changes are lost?
- Try putting Fabrikam read-only before the snapshot. What happens to the read-only time?
Pass rule: all of Fabrikam's data stored and served in the EU; the move loses no changes, keeps read-only time to 15 minutes or less, ends with writes on, and keeps the old copy until the new one is checked.
Residency also shapes who can read the data: support staff outside the EU may need a customer's permission, logged in the audit trail from Lesson 7, to open its tickets. Plan support tooling per region from the start.
Check Yourself
Common mistakes
| Mistake | Wrong | Correct | Why it happens |
|---|---|---|---|
| Residency = database only | Logs and backups go to the US | List and place every copy | Each tool was added separately |
| Nearest-region routing | A traveller's request is served in the US | Route by tenant, not by user location | It is the CDN default |
| Cells that call each other | One cell's outage spreads | Cells are independent | Shared code is convenient |
| Snapshot without change streaming | Writes during the copy are lost | Start change data capture first | The copy looks like the whole job |
| Long read-only window | Read-only for the whole 2-hour copy | Read-only only for the final catch-up | It is the simplest safe plan |
Practice
What to Remember
- Residency covers every copy and every place that processes the data.
- Cells are independent stacks; a tiny global directory routes tenants to them.
- Keep backups, logs and indexes in the cell's region.
- Move tenants with change streaming, a short read-only catch-up, a switch, and a check before deleting.
Further Reading
- AWS Well-Architected: Reducing the scope of impact with cell-based architecture: how cells work and how to route to them.
- Slack Engineering: Slack's migration to a cellular architecture: moving a large product to cells.
- European Data Protection Board: Guidelines on international data transfers: the rules behind EU residency contracts.
Next: Usage Metering and Billing. Customers pay for what they use. You count every event exactly once, handle the one that arrives after the invoice went out, and prorate a plan change.