SSE is 30 lines on one pod. The second pod is where the engineering starts

The sink map is the part that does not survive contact with a load balancer. Each pod lazily builds a per-user `Sinks.Many` when someone subscribes, hands out its `Flux`, and deletes the sink when the last subscriber leaves ^[9]. That map is the only record of who is listening on that process, so a publish is a local lookup and nothing more. Redis pub/sub exists in this design purely to make pod B's write visible to pod A's map ^[14], because a count incremented on pod B lands in pod B's sink map and User 42's open connection on pod A never hears about it ^[13].

Which turns the lifecycle race into an operational problem rather than a curiosity. The author's sequence is precise: the `Flux` is returned holding a sink reference, the previous subscriber for that user unsubscribes, cleanup removes the sink from the map, a publish arrives and finds nothing to deliver to, and only then does the downstream attach to the orphan ^[10]. `Flux.defer` fixes it by rebuilding the map lookup at the moment the downstream attaches ^[11]. The reason that matters at scale is the stream's own design: the server hangs up after 30 minutes and the client reconnects with a fresh token ^[8], which is two unsubscribe-then-subscribe cycles per hour for every continuously connected user ^[17]. A window you would never hit by hand is now entered on a timer, on every pod, for every user.

Same timer, same arithmetic, on the cost side. A full-length connection carries 60 heartbeat comments ^[16], since the ping goes out every 30 seconds to keep intermediaries from treating an idle stream as a dead one ^[6]. Each reconnect also repeats the synchronous unread-count read that the endpoint does on subscribe ^[5], so the floor is two count queries per hour per connected user before anyone gets an actual notification ^[18]. That read was introduced to save the client a REST round-trip for first paint ^[5]; the forced-close policy hands part of it back twice an hour.

The backpressure choice is the one worth copying carefully. `directBestEffort` drops events for a slow subscriber instead of tearing the stream down, and the stated justification is payload-specific: the latest unread count replaces any count that got dropped ^[12]. That reasoning holds for a counter and stops holding the moment an event carries information no later event repeats, because the client is never told a drop happened. The published pattern advertises ordering gotchas alongside the lifecycle ones ^[15], and this is where they come from: a cross-pod bus feeding a local best-effort sink gives the browser no way to detect a gap unless something in the payload numbers itself.

Two of the remaining details are admissions about hops nobody in this codebase owns. `X-Accel-Buffering: no` is described as a hint to reverse proxies, which buffer by default and will hold events until the buffer fills ^[7] - a hint an unfamiliar proxy is free to ignore. The heartbeat is there because SSE looks idle to TCP intermediaries ^[6]. Both are workarounds for infrastructure behaviour, not application logic, and neither shows up in the single-pod version that took 30 lines ^[2].