Skip to content

PATTERN Cited by 1 source

Single HTTP request over chatty WebSocket

Problem

A multi-step RPC flow is implemented over a long-lived WebSocket between a worker and a remote endpoint. The worker sends instructions one at a time — open page → navigate URL → wait for load → take screenshot — each step requires completion before the next begins. The user-visible latency is sum of (server-side execution + per-step round-trip), where the per-step round-trip is paid N times for an N-step flow.

When the steps are deterministic (the worker always sends the same sequence in the same order) and the parameters are known in advance, the chatty protocol is N× more network-bound than it has to be.

Pattern

Coalesce the multi-step protocol into a single HTTP request that ships all parameters up-front. The receiver executes the entire flow internally — no further worker↔receiver round-trips. The HTTP response carries the final result of the flow.

Before:                                After:
  worker          remote                worker         remote
    |  open page    |                     |  POST       |
    |-------------->|                     | (all params)|
    |<--------------|                     |------------>|
    | (page open ok)|                     |             | -- internal:
    |  nav URL      |                     |             |    open page
    |-------------->|                     |             |    nav
    |<--------------|                     |             |    wait
    |  wait for load|                     |             |    screenshot
    |-------------->|                     |<------------|
    |<--------------|                     | (final blob)|
    |  screenshot   |
    |-------------->|
    |<--------------|
   (4 round trips)                       (1 round trip)

Verbatim canonical articulation

From the 2026-05-13 Browser Run migration (Source: sources/2026-05-13-cloudflare-browser-run-now-running-on-cloudflare-containers-its-faster):

"Previously, our workers established a WebSocket to the remote browser and sent instructions one at a time: open a page, navigate to the URL, wait for it to load and take the screenshot. Each step had to be completed before the next could begin. However, now we send all parameters in a single HTTP request directly to the container, and the entire flow executes internally without any back-and-forth between the worker and browser."

Headline outcome (combined with regional pre-warmed-pool placement bounding): >50% reduction in Quick Action response times.

Preconditions

  1. The flow is deterministic — the steps and their order are fixed at flow-template time, not chosen step-by-step based on intermediate results.
  2. Parameters are known up-front — every step's parameters can be supplied in the initial request. Step-by-step adaptation isn't needed (or, if it is, it's encoded into the receiver's internal flow logic, not exposed at the protocol).
  3. Receiver can execute the flow autonomously — the receiver has the runtime, libraries, and authority to execute every step internally without intermediate worker decisions.
  4. No mid-flow user input or ML-decision-from-intermediate- result is required — those workloads need the chatty shape.

When the pattern fits

  • Browser-automation Quick Actions — screenshot, content extraction, PDF generation: deterministic flow, known parameters.
  • Composite document operations — fetch + transform + return pipelines.
  • Pre-baked workflows — any multi-step sequence the worker knew was always going to send the same N messages anyway.

When the pattern doesn't fit

  • Interactive sessions — debugger sessions, REPL-style agent control, real-time ML control loops where the next message depends on the receiver's intermediate output.
  • Streaming protocols — stdin / stdout style where the response stream is the work product.
  • Bidirectional message-passing — agent ↔ tool with uncertain message counts.
  • Operations whose internal flow you can't trust the receiver with — sandboxing, cross-tenant safety, etc.

Failure modes

  • No mid-flow visibility. The worker doesn't see step-by-step progress; if step 3 of 4 fails, the worker only learns about it from the final HTTP response (or a timeout). Long flows may need server-side logging on the receiver to be debuggable.
  • All-or-nothing semantics. Partial completion — "page loaded but screenshot failed" — is harder to express in a single response. The receiver's internal logic must define what partial-success looks like.
  • Timeout sensitivity. The single HTTP request must wait for the entire flow; bounding the request timeout is now a per-flow decision rather than a per-step decision.
  • Parameter envelope sprawl. As flows accumulate steps, the request body grows. May need versioning / schema discipline.
  • Testability shift. Unit-testing each step is harder; the receiver-internal flow must be exercised end-to-end.
  • Fits poorly with fan-out flows. If step N's output is consumed by both the worker and a downstream receiver, the fan-out point either needs to be inside the receiver or moved out of the coalesced request.

Composes with

  • patterns/regional-pre-warmed-do-container-pair-pool — reduces the multiplier on the bound that pattern imposes. Browser Run applies both: regional pools cap worst-case DO-Container distance; this pattern reduces the number of round-trips that distance is paid on. The two optimisations are multiplicative on user-visible latency.
  • concepts/do-to-container-cross-region-rtt — the chatty-protocol amplifier of cross-region RTT. Coalescing eliminates the per-message multiplier even when cross-region RTT remains.

Seen in

Last updated · 542 distilled / 1,571 read