Region Pinning
also called Home Region Assignment, Tenant Region Affinity
Binding each tenant's data and request handling to one named region, recorded as a routing attribute, so locality is enforced at the edge instead of by replicating everything everywhere.
A B2B platform runs in one US region. 38% of revenue now comes from Australia and Europe, where p95 page load is 1.9 seconds against 420 ms in North America, and churn there runs over twice the US rate. The obvious response - replicate globally and let anyone write anywhere - buys cross-region write conflicts, a consistency model nobody can explain, and a cost multiplier on every byte.
Region pinning takes the other route. Each tenant has one home region, recorded as an attribute, and every request for that tenant is routed there. One writer, no conflict resolution, one copy of the data. The cost is a global tier and a routing layer that must never be wrong.
Why it matters
Most multi-tenant products have a natural partition the physics is happy with: a tenant's users are usually in one place, and tenants almost never share data. Pinning exploits that to get regional latency without distributed writes - the hardest part of multi-region is avoided rather than solved - and it gives a straight answer to "where does this customer's data live", which a globally replicated design cannot.
The decision is near-irreversible in one direction: once tenants exist in two regions, every region needs the global tier, so its availability becomes the platform's ceiling, and returning to one region requires a second migration.
Implementation patterns
- One authoritative region attribute, written by one process and read by the edge, the API gateway and every background job. Two sources of truth for a tenant's region is the defining failure of this pattern.
- Resolve the region before authentication, from the tenant identifier in the hostname, path or token, and key every cache and search index by region, or one region serves the other's data until entries expire.
- Separate global from regional data before the first tenant moves. Login identity, the tenant-to-region directory, billing and cross-tenant admin cannot be pinned.
- Make migration a per-tenant operation: freeze writes, copy, verify checksums, flip the attribute, unfreeze - minutes per tenant, individually reversible, with the source copy kept 30 days so the flip stays reversible through a full business cycle.
Industry example
This is the standard shape for business-to-business platforms serving several jurisdictions, and for consumer marketplaces across adjacent countries - a ride-hailing operator in several Southeast Asian markets has the same structure, where a rider, a driver and a trip all belong to one city and only identity and payments are global. The characteristic difficulty is the global tier rather than the pinning: identity is needed in every region on every request, so it ends up replicated read-only from a single write region, and its failover becomes the platform's most rehearsed procedure. This is the shape of the problem, not any one operator's published design.
Failure scenarios
- Split-brain on the attribute, where identity says one region, the data lives in another, and the tenant sees an empty account.
- Writes that bypass the router. A cron job or webhook handler writes to the old region during a freeze, and the divergence is found weeks later.
- A global tier with no availability target, extracted as plumbing and now a single point of failure for every region.
- Queued work crossing the flip, processed after it against the old database.
- Residency assumed rather than enforced, with telemetry or a support tool still copying the data elsewhere.
Trade-offs
| Choose | Gains | Pays |
|---|---|---|
| Region pinning | Local latency with one writer; per-tenant migration | A global tier that becomes the availability ceiling; permanent routing correctness |
| Global replication | Any user served anywhere | Write conflicts; full data cost per region |
| Single region | Simplest to operate | Round-trip time as a product defect |
When not to use it
When the product's data is inherently cross-tenant - a global social graph, a marketplace where any buyer matches any seller - pinning cuts across the data and the cross-region joins cost more than the latency saved. Skip it too when server time is a small part of the latency: if 180 ms of a 1.9-second p95 is server work, a content delivery network and front-end work buy more in weeks than a region programme buys in two quarters. And if the requirement is residency, pinning is necessary but not sufficient, because it says nothing about which components may see the data.
Interview question
Q: You are pinning tenants to home regions on a live platform. What do you build first, what do you move last, and what is the point of no return?
What a strong answer covers: the region attribute and routing proven in production while every tenant still resolves to one region; the global tier extracted and given its own availability target before any tenant moves; per-tenant freeze-copy-verify-flip as the unit of migration; and deleting the source copy as the real point of no return, with the global tier becoming the platform ceiling as the step that is irreversible earlier.
Quick check
Quiz: Which data cannot be pinned to a tenant's home region? Login identity, the tenant-to-region directory, billing, and anything cross-tenant such as admin search.
Flashcard: In a home-region design, what is the point of no return? — Deleting the source region's copy of a tenant's data; the attribute flip reverses in seconds.