A collaborative editor must feel instantaneous to users on different continents, where physics imposes a floor of roughly 150 ms round trip. How is the latency requirement met at all?

The reframing

The requirement is not "make the round trip fast". It is "make the user not wait for a round trip". Those are different problems, and only the second is solvable.

Physics sets a hard floor: light in fibre between distant continents is roughly 150 ms round trip before any processing. No server topology, protocol optimisation or CDN removes it. So the architecture must ensure the user's own actions do not depend on it.

How it is met

1. Local-first application. Every edit applies immediately to the client's own replica. The user sees their change at input latency, not network latency. This is not an optimisation layered on top; it is the architecture, and no server-side design substitutes for it.

2. Conflict-free merge semantics, so local application can be optimistic without ever needing to be retracted. If concurrent operations commute, applying locally and reconciling later is safe by construction — which is what makes optimistic UI honest rather than a lie that occasionally gets corrected.

3. Latency to others' changes is far less perceptible. Seeing a collaborator's cursor move 200 ms late is unnoticeable; seeing your own text appear 200 ms late is intolerable. Recognising this asymmetry is what lets the design spend its latency budget where it does not matter.

4. A single authoritative session per document, hosted where its collaborators actually are, acting as sequencer. A distant participant sees their own edits instantly and others' after one round trip.

What separates perceived from measured latency

• Input latency, below roughly 50 ms, is the threshold at which interaction feels direct. This is a client rendering problem, not a network one.
• Optimistic rendering removes the network from the perception loop entirely.
• Progressive rendering — showing structure before content — makes a slow operation feel faster than a blank wait of the same duration.
• Predictable latency beats lower average latency. Users adapt to consistent delay and are disturbed by variance, which is why p99 matters more than p50 for perceived quality.

The general principle

For interactive systems, measure and optimise the latency of the user's own action, and treat everything else as a background reconciliation problem. Teams that optimise average server response time for a collaborative product are optimising a number that has almost no relationship to how the product feels.