A residency commitment sounds like a storage decision: put this customer's records in this region and keep them there. The storage is the straightforward half. The half that gets discovered late is that something has to know which region a request belongs to, and that something cannot itself live in one region.
Every regional architecture has a global tier, whether or not anybody designed it. The difference between systems that hold up under a review and systems that do not is whether that tier was deliberate, thin and documented, or accumulated by accident.
What is global by construction
The routing table is unavoidable. A request arrives at a hostname before anyone knows who is asking, and the mapping from a domain, an organisation identifier or a tenant slug to a region has to be readable from wherever that request lands. So must the sign-in hostname, if you have one shared entry point, because the person typing their address has not yet been resolved to anything.
Then there is the ordinary business machinery: billing, plan entitlements, the support tooling your staff use, the status page, the deployment pipeline. None of it is exotic and all of it spans regions, because your company does. The commitment you made was about customer data, and being precise about that distinction is what keeps this conversation honest rather than defensive.
- Domain, slug or organisation identifier to region — read on every unauthenticated request
- The sign-in entry point, which must resolve a person before it can route them
- Billing and entitlement state, which lives with your company rather than with the tenant
- Internal operational tooling, deployment control, and aggregate telemetry
Keep it boring and keep it thin
The global tier should hold the smallest set of facts that makes routing possible, and those facts should not be personal data. An organisation identifier and a region code is a good target. An organisation identifier, a region code, a display name, an owner email and a signup source is how it usually ends up, one convenient addition at a time, each justified by a dashboard somebody wanted.
Defend it with a rule rather than with vigilance: the global store has a small schema, changes to it require a reviewer who knows why the boundary exists, and no service in the global tier is allowed to call into a regional one for content. It exists to answer where, and to answer nothing else. That sentence is also the one you will read out in a security review, so it is worth being able to say it accurately.
The global tier answers one question: where. The moment it starts answering what, the residency promise has a hole in it.
The features that want to cross
Product requirements will push against the boundary, and the pressure is always reasonable in isolation. A global search across a customer's workspaces. Analytics aggregated across regions. A single support console where staff can see everything. Notification email, which leaves your infrastructure entirely and lands wherever a mail provider decides.
Each of those needs an explicit decision recorded somewhere a reviewer can read: this crosses, that does not, and this one crosses in aggregate form that cannot be attributed to an individual. Notification content is the sharpest case, because the body of an email routinely contains exactly the data you promised to keep in a region. A residency claim that has not thought about email is one follow-up question away from unravelling.
Failure, backups and the promise under stress
A region outage is where residency commitments are tested. If your failover plan moves traffic to another region, it moves data with it, and that is either permitted by what you promised or it is a breach of it. Decide in advance which it is: recovery within the boundary and accepted downtime, or a documented exception the customer agreed to in writing.
The same applies to the copies nobody thinks of as storage. Backups, log aggregation, error reporting with request payloads attached, the crash dumps a client library uploads by default. Those pipelines cross regions unless someone stopped them, and they carry exactly the content in question. Write the residency claim only after you have traced where each of them physically writes, because a claim that survives the review but not the practice is the worse of the two failures.
- Decide whether failover may cross the boundary, before the day it matters
- Trace backups, logs and error reporting; they are storage even when nobody calls them that
- Keep disaster recovery within the boundary where the promise requires it, and say so
- State the promise in terms of what data, not in terms of which servers you happen to run
Everything here, already built
Sign-in, enterprise SSO, directory provisioning, roles and an audit trail behind one API. Start with the quickstart and have a working sign-in this afternoon.