Should one Server-Sent Events response stay open for a fourteen-hour firing, and how would you bound its lifetime?
answer
- the feed is not the response
- treat a response as a lease
- reconnect is free, so use it
- complete the body, do not cut it
- an open response pins its placement
basics
~20 sUsually not. Cap a response's lifetime at minutes to an hour and end it deliberately by completing the body; a conforming client re-opens by itself. An unbounded response pins a connection slot, its subscription, and the viewer to one instance.
solid answer
~50 sA fourteen-hour feed does not require a fourteen-hour response. The protocol already gives you client-driven re-opening for free, so the emitting side can treat one response as a **lease** rather than as the lifetime of the subject. Pick a maximum — commonly minutes to an hour — and when it expires, finish writing the body and complete the response. The client sees the stream end and opens a new one after its delay. That converts an open-ended commitment into a bounded one: an abandoned or stuck response cannot outlive its lease, a deployment can drain within one lease instead of cutting live viewers, and per-instance connection counts stay predictable because every viewer is re-placed regularly. End it, do not drop it: completing the response is a clean end, whereas cutting the connection hands the receiving application an error for a shutdown you chose.
go deeper
The takeaway is that a client re-opens a stream by itself, so a server is allowed to end one on purpose without anything being broken.
Explain what an open response holds — a connection slot, a live subscription, a registry entry — and why ending the body cleanly differs from dropping the connection.
Demonstrate the operational case: a lease makes deployments drainable, keeps placement re-balanceable, and caps any single stuck response, at the price of a gap per handover.
The call to own is the lease length itself, traded against request volume, gap coverage, and how fast a fleet needs to be able to drain and re-balance.
## An open response is an open commitment A held response is not free just because it is idle. For as long as it is open it holds: - **A connection slot**, and on a thread-per-request concurrency model a thread with it. - **A live subscription** to whatever source feeds it, plus any buffers or state that subscription pins. - **A registry entry** that every publish walks in order to fan out. - **A placement decision.** The viewer was assigned to one instance when the request arrived, and stays on that instance for as long as the response lives. Nothing re-balances a response that is already open. The last one is the one candidates miss, and it is the most operationally expensive. A fleet where responses last fourteen hours is a fleet where a newly added instance stays nearly empty and a deployment either waits out the longest response or cuts live viewers. ## Why a bound is available here at all This protocol's defining property is that the client re-opens on its own, without application code in the path. That is normally discussed as resilience — a dropped stream heals itself — but it is also **permission**: the emitting side may end a response whenever it likes and expect the viewer to come back. A duplex channel has no such affordance unless the application builds one. So a response can be treated as a lease over a feed rather than as the feed itself. The subject runs for fourteen hours; any individual response over it runs for as long as you decide. ## Choosing and enforcing the bound 1. **Pick a maximum lifetime** the feed can tolerate a gap in. Minutes to an hour covers most cases; shorter re-places viewers faster and multiplies request volume, longer does the reverse. 2. **Track it from the moment the response opened**, not from the last event, so a busy stream is bounded exactly like a quiet one. 3. **When it expires, finish the body and complete the response.** No error, no cut connection. 4. **Run the same cleanup as any other exit** — cancel the subscription, drop the registry entry, release the response. A deliberate end is still an end. ## Ending versus dropping | | complete the response | drop the connection | |---|---|---| | what the receiver sees | the stream ended normally | a transport failure | | what the application sees | a stream that finished | an error it must classify | | what happens next | the client opens a new request after its delay | the same, after noise in the logs | | what it tells an operator | a planned handover | indistinguishable from a real fault | Both end up reconnecting, which is why this looks like a distinction without a difference until something is actually wrong: once every planned handover is spelled as a failure, the failures that matter are unreadable. ## What the bound does not solve - **The gap.** Between the end of one response and the arrival of the next request there is a window in which events can occur. Whether anything fills that window — how the client says where it stopped, and what the emitting side replays — is the resumption problem and a separate subject entirely. - **Silence.** A leased response still needs its idle writes; the lease bounds the response, not the quiet inside it. - **Buffering on the path.** A short lease makes a stalled response self-correct sooner, which flatters the symptom without addressing the cause. - **The per-viewer cost.** Re-opening is cheaper than an initial connection but not free; a one-minute lease across many thousands of viewers is a steady request rate you chose. ## The judgment being tested The interviewer wants to hear that "how long should this response live?" is a decision with a cost on both sides, not a property inherited from the subject being watched. A candidate who answers "fourteen hours, because the firing is fourteen hours" has not separated the feed from the response. A candidate who answers "thirty seconds" has turned a streaming protocol into expensive polling. The good answer names the bound, says what it buys — drainable deploys, re-balanceable placement, a ceiling on any single stuck response — and admits what it costs: a gap per handover that something else has to cover.
- What does ending a response deliberately look like, as against dropping it?You stop writing, complete the response body, and run the usual cleanup. The receiving application sees a stream that ended and opens a new request after its delay. Dropping the connection produces the same reconnection but presents a planned handover as a transport failure, which buries real faults in noise.
- Does a bounded lifetime lose events across the handover?It can. Between the end of one response and the next request there is a window. Whether it is filled belongs to resumption — the client identifies where it stopped and the emitting side decides what, if anything, it replays — so a bound is only safe once you know what covers the gap.
- What actually improves when responses are short-lived?Placement and drainage. Viewers are re-assigned on every handover, so a newly added instance fills and a departing one empties within one lease instead of waiting out the longest response. Any single stuck or leaked response also has a ceiling on how long it can cost you.
A shop keeps a phone line open all afternoon to shout the occasional update down it. Nothing is wrong with the line — the cost is that a handset is tied up and that customer is stuck with whoever picked up, until someone hangs up politely and they call back.
saying these in an interview costs you the question
- Assumes a fourteen-hour feed needs a fourteen-hour response.
- Cuts the connection at the deadline instead of completing the response.
- Says an open response costs nothing while it is idle.
- Forgets that a held response pins a viewer to one instance.
- Treats every reconnection as a fault rather than a designed handover.
- Sets a bound without deciding what covers the gap.