A collaborative design tool has users in one document spread across continents, needing sub-100 ms feedback on every edit. Should the document's authoritative state be multi-region writable, single-region, or something else?

The core tension

Sub-100 ms feedback across continents is impossible if every edit requires a round trip to a distant authority — physics sets a floor of roughly 150 ms round trip between distant continents, before any processing.

But making the document multi-region writable introduces concurrent writes to the same logical object across regions, which is the hardest problem in distributed data and produces conflicts that no architecture resolves invisibly.

The resolution: separate perceived latency from authoritative state

Local-first at the client. Edits apply immediately in the client's own replica. The user never waits for any network round trip for their own action. This is what actually delivers the latency requirement, and no server topology can substitute for it.

A single authoritative session per document. The document's live editing session is hosted in one region — chosen by where its collaborators actually are — and acts as the sequencer. All participants connect to it. A distant participant sees their own edits instantly (local application) and others' edits after one round trip, which is acceptable because latency to other people's changes is far less perceptible than latency to your own.

Conflict-free merge semantics so that concurrent operations commute and the session's ordering is a convenience rather than a correctness requirement. This is what lets clients apply optimistically and reconcile without ever retracting a user's work.

Regional read replicas for everything that is not the live session — file listings, thumbnails, permissions, team metadata. These are read-heavy, tolerate staleness, and dominate the requests outside an editing session.

Why not multi-region writable

Because it buys very little and costs a great deal here. The latency win applies only to the edit round trip, which local-first has already eliminated. In exchange you accept concurrent cross-region writes to the same document, conflict resolution that must be correct across regions, ambiguous failover semantics, and cross-region replication cost on the hottest path.

The single-writer-per-document model is dramatically simpler and delivers the same user-perceived latency.

What must still be handled

• Session placement and migration. A document whose collaborators shift geographically should migrate its session, which requires draining and re-establishing connections without losing operations.
• Disconnection. A client offline for minutes must be able to reconnect and merge — which the conflict-free model provides, but the buffer sizing and the fall-back-to-full-resync path must be designed.
• Regional failure. Losing the session's region means sessions must be re-established elsewhere from durable state. Documents must be recoverable from a replicated log, so the region hosting the session is not the only place the data exists.
• Permissions, which do not converge. Authorisation must be checked against an authoritative source; an offline client's edits to a document it has lost access to are rejected on reconnect.

The transferable principle

Move the latency-critical computation to the client and keep the authority in one place. Multi-region writable data is a genuine requirement for some systems, and it is far more often reached for as a latency solution when a local-first client would have solved the latency problem without any of the distributed-write cost.