Skip to content

CONCEPT Cited by 1 source

DO-to-Container cross-region RTT

DO-to-Container cross-region RTT is the latency additivity hazard introduced by DO-enabled Containers when the Durable Object is placed near the user but the connected Container spins up in a different region — possibly "on the other side of the world". For one-shot RPCs this is invisible (one extra one-way trip on a control-plane action). For chatty multi-message protocols the DO-to-Container RTT is paid per-message, and an interaction that nominally takes "a few hundred milliseconds" balloons by N × cross-region-RTT.

Mechanism

DO-enabled Containers create a Durable Object as close to the incoming request as possible, but the connected Container's location is independent. Two placement decisions, two latency hops:

[user] --1ms-- [POP] --DO-place--> [DO]   ← close to user, fast
                                    |
                                    | DO-Container hop
                                    v
                                  [Container]  ← may be far

For a screenshot request that requires the worker to:

  1. Open the page
  2. Navigate to the URL
  3. Wait for it to load
  4. Take the screenshot

…each step is a WebSocket message between DO and Container. If the DO is in weur and the Container is in apac, every message pays the inter-continental RTT. The user-visible latency is dominated by N_messages × cross-region-RTT rather than by the page-load time itself.

Verbatim canonical articulation

Cloudflare's own framing (Source: sources/2026-05-13-cloudflare-browser-run-now-running-on-cloudflare-containers-its-faster):

"DO-enabled Containers create a Durable Object as close to the incoming request as possible, but the connected Container may spin up on the other side of the world. This works fine for one-shot messages like 'start my app,' but when you're establishing a WebSocket between them and exchanging dozens of messages for a screenshot request, those extra milliseconds crossing the globe start adding up."

Two distinct properties named in this single paragraph:

  1. DO and Container placement are independent. The DO's placement (near user) does not constrain the Container's placement.
  2. Chatty protocols amplify the cost N×. A 50 ms transcontinental hop times 30 message exchanges is 1.5 seconds of latency the user-visible flow inherits from the DO-Container distance.

Solutions named in the source

The 2026-05-13 post describes two architectural responses, used in combination:

  1. Constrain placement to within a region — regional pre-warmed pools of DO+Container pairs make the "DO-Container pair closest to the user within that region" the unit of selection. DO-Container distance is bounded by the region's diameter (typically intra-continent), not by the platform's global footprint.
  2. Coalesce the chatty protocol into a single request — patterns/single-http-request-over-chatty-websocket sends all parameters in one HTTP request directly to the Container and the entire flow executes internally. Even if the DO and Container were far apart, only one round-trip pays the distance cost.

In Browser Run's migration, both were applied. Solution (1) bounds the worst case; solution (2) reduces the multiplier on the bound.

Distinction from sibling concepts

  • concepts/network-round-trip-cost — generalises per-record-loop latency over any RPC boundary. DO-to-Container cross-region RTT is the placement-decoupling variant where the boundary is internal to a single platform's fabric and the per-message cost is dominated by physical distance the application doesn't choose.
  • concepts/cold-start — the time to provision a Container is paid once. DO-to-Container RTT is paid every message thereafter.

Implications for placement design

  • DO-Container pair allocation should be a single decision, not two independent ones, when the workload is chatty.
  • The bounding scope (region) must be narrower than the platform's global footprint, but wider than a single data centre, to leave room for capacity rebalancing without violating the latency budget.
  • "Pre-warmed" matters because creating the pair on demand re-introduces the placement-decoupling-decision-window risk.

Seen in

  • sources/2026-05-13-cloudflare-browser-run-now-running-on-cloudflare-containers-its-faster — canonical wiki instance. Browser Run's screenshot path was WebSocket-based with dozens of messages per request; the DO-Container distance was the dominant latency contributor before migration. Solution: regional DO+Container-pair pools for placement bounding + single-HTTP-request quick-action protocol to reduce the multiplier on the remaining bound.
Last updated · 542 distilled / 1,571 read