advanced 2 min answer

A collaborative product must decide between single-region, multi-region read replicas, and multi-region writable. What should decide it?

multi-regionlatencycomplexitylocal-firstfigmaarchitecture-selection
Show the full answer Hide the answer

What should decide it

What problem multi-region is being asked to solve. The three candidates have different answers:

Latency for users far from the primary region. Frequently solvable without multi-region writes at all. For an interactive product, a local-first client — applying edits immediately to a local replica with conflict-free merge — eliminates the round trip for the user's own actions, which is where perceived latency lives. Latency to other people's changes is far less perceptible.

Availability during a regional failure. Requires data replicated and a failover path, which is warm standby or active-active, and the choice follows from the tolerable recovery time and data loss.

Data residency. A regulatory constraint that dictates deployment topology and is not negotiable by architecture.

The ladder

1. Single region with a local-first client and regional read replicas for the read-heavy, staleness- tolerant data — file lists, thumbnails, permissions, metadata. This handles most latency and most read scale.

2. Multi-region with a single writer per entity. The document's live session is hosted in one region chosen by where its collaborators are, and everything else reads locally. Dramatically simpler than multi-writer and delivers the same user-perceived latency.

3. Multi-region writable, which introduces concurrent cross-region writes to the same object — the hardest problem in distributed data, with conflict resolution, ambiguous failover semantics and cross-region replication on the hottest path.

The question that usually settles it

"Which entity would be written concurrently from two regions, and what does correctness require when that happens?"

If the answer is "no entity, because a document has one session at a time", multi-region writable is solving a problem you do not have. If it is "any entity, because users move between regions", the complexity is genuine and must be confronted.

What must be handled regardless

Session placement and migration as collaborators shift geographically; recovery from a replicated log if the hosting region fails; and permissions, which do not converge — authorisation must be checked against an authoritative source, and offline edits to a document the user has lost access to are rejected on reconnect.