Entity Homing

Multi-region design usually presents a false choice: one global write primary (simple, and a single point of failure with poor write latency for distant users) or globally replicated writes (low latency, and a conflict resolution problem nobody can reason about for anything with an invariant).

Entity homing takes a third path: partition by entity and give each partition a home region that owns its writes. Reads are served everywhere from replicas; writes for an entity go to its home.

Why it matters

It converts a global availability question into a per-entity one. A regional outage stops writes for the entities homed there and leaves everything else working, which is a far better failure profile than a single global primary — and it does so without inventing merge semantics for concurrent writes.

It also gives genuinely local write latency for the majority of users, since an entity can be homed near the people who use it.

Implementation patterns

• Choose the homing key to match the consistency invariant — the account for a wallet, the tenant for a SaaS workspace, the instrument for an order book. It is the same decision as choosing a partition key, and equally expensive to change later.
• Resolve the home at the edge, and route write requests there. Reads stay local.
• Store the mapping in globally replicated configuration, and treat it as slow-changing so it can be cached aggressively.
• Make relocation a supported operation, online: replicate to the new home, verify, brief write pause, cut over, keep a rollback. Homing that cannot be changed is a decision you will regret when a customer moves or a region becomes expensive.
• Decide the outage policy explicitly. Automatic failover of a strongly consistent writer risks two writers and a split history; a quorum-based mechanism or a human decision is the safer default for anything financial.
• Handle cross-entity operations as an explicit protocol — a transfer between two accounts homed in different regions is a saga, not a transaction, and pretending otherwise is where correctness fails.

Industry example

Platforms such as Fly.io are built around placing application instances close to users while state remains harder to distribute, which makes the read-local, write-home pattern the natural shape. The same structure appears in multi-tenant SaaS where each tenant is homed in a region for both latency and data-residency reasons — and residency requirements often force homing regardless of performance, which is a case where the regulation makes the architecture decision.

Failure scenarios

• A homing key that does not match the invariant, so writes for one logical entity land in two regions.
• Automatic failover of a write primary, producing two writers and a split history.
• No relocation capability, so homing is permanent and every customer move is a project.
• Cross-entity operations assumed to be transactional, which they cannot be across homes.
• The home lookup on the request path with no caching, making the configuration store a hard dependency of every write.

Trade-offs

Homing gives up global write availability for any single entity: if its home region is down, its writes stop. That is a deliberate choice of consistency over availability for the operations where consistency is the point, and it should be stated in the availability model rather than discovered.

It also adds routing complexity and a mapping to maintain, and it makes any operation spanning entities in different homes materially harder. The alternative — global writable replication — moves that difficulty from the rare cross-entity case into every single write, which is why homing is usually the better trade.

Interview question

"A customer's home region is unavailable. They can read their balance but not transfer money. Defend that design to the customer, and then tell me under what circumstances you would allow the write to proceed elsewhere."