A Server-Sent Events feed streams smoothly in local tests but arrives in clumps through a reverse proxy — why?

## The symptom, stated precisely A bottling line publishes jam-and-speed events from the filler and capper as `text/event-stream`. Against a laptop on the plant floor, talking to the origin directly, each event lands the moment the line reports it. Published through the site's edge tier, the same feed goes quiet and then delivers twenty events at once, each carrying a timestamp showing it was produced seconds apart from its neighbours. Nothing is lost. Everything arrives, in order, correctly framed. Only the timing is destroyed -- which is the entire product. This is the failure that never appears in a test and always appears after deploy, because a test has no intermediary in the path. ## Why an intermediary is allowed to do this HTTP tells an intermediary what a message means. It does not oblige it to pass along a piece of one promptly. A proxy that reads an upstream response into a buffer and writes downstream when the buffer fills is doing something entirely reasonable for the traffic it was designed for: fewer and larger writes toward the client, upstream connections released sooner, and a slow reader insulated from the origin. For a response that ends, the only cost is a few milliseconds. For a response that never ends, the buffer becomes the delivery schedule. This is a documented hazard rather than a surprise: RFC 6202, which collects the known issues in long polling and HTTP streaming, records intermediary buffering as one of the central obstacles to streaming over HTTP. ## Bytes, not seconds -- the diagnostic that names the cause One observation separates the two candidate causes: - Clumps that track a **byte size** point downstream. A fixed buffer releases on a size boundary, so a feed of small events clumps in larger counts and a feed of large events clumps in smaller ones, while the elapsed gap between clumps varies with how fast the line is running. - Clumps that track an **interval** regardless of event size point upstream, into the producing code or a scheduler that gathers events before writing them. Compare arrival timestamps at the receiver against the write timestamps at the origin and the two separate in a single pass. ## The levers, in the order worth trying 1. **Request the same path from the origin directly**, bypassing the edge tier. This confirms in one command that the origin writes incrementally and moves the investigation downstream. 2. **Disable response buffering for that route** in the intermediary. This is the real fix, and it is configuration in someone else's tier rather than code in yours -- which is why this failure so often crosses a team boundary. 3. **Send the per-response opt-out field.** Many proxies honour a vendor-defined response header field that turns buffering off for one response. No specification defines such a field, the spelling differs by product, and an intermediary that does not recognise it ignores it silently. Useful, not dependable. 4. **Keep the stream off the buffering path**, on a route or hostname that does not traverse the tier that buffers. 5. **End-to-end TLS through transparent intermediaries.** Something that cannot read the body cannot usefully accumulate or re-frame it, and this was the historical recommendation for HTTP streaming. It does nothing about a reverse proxy in your own edge tier that terminates TLS by design. ## What does not fix it | Attempted fix | Why it does not work | |---|---| | Adding cache directives | `no-cache` and `no-store` govern reuse and storage, not when received bytes are forwarded | | Padding events to fill the buffer | Guesses at a size you do not control, and breaks when the tier is reconfigured | | Switching the response to HTTP/2 or HTTP/3 | An intermediary that buffers a body buffers it under any version | | More flushing at the origin | The origin's writes already left; they are sitting in someone else's buffer | That last row is the one candidates most often get backwards. The emitting side's flush discipline is a real duty and a real bug when it is missing, but it is a **different** bug: when the origin is at fault, a direct request to the origin clumps too. When an intermediary is at fault, the direct request is smooth and only the published path clumps. ## Why the origin's own monitoring is silent There is no error to log. The origin wrote the bytes, the write returned, the response is still open and the client has not disconnected. Every counter the origin owns says the stream is healthy. The stall lives entirely in the gap between two hops, and the only place it is visible is at the receiver's clock -- which is why this failure is usually first reported by a user saying the dashboard "feels laggy" rather than by an alert.