Across a fleet of long-lived Server-Sent Events feeds, how would you set a maximum response lifetime to fix how often streams re-authorize?
answer
- the decision lives as long as the response
- bounding the response bounds the staleness
- no client code required
- every ending is a paid reopen
- tier by sensitivity, stagger the endings
basics
~20 sSet it as a staleness budget: an authorization decision lasts exactly as long as its response, so the maximum lifetime you allow is the maximum staleness you are promising. Tier it by how sensitive the feed is, and price the reopens.
solid answer
~40 sStart from the fact that makes this a policy question at all: a stream is authorized once, at open, so the decision's life *is* the response's life. Bounding the response is therefore the one lever that turns an unbounded window into a number you can state — and because a conforming client reopens by itself, the bound costs you no client code. Then price it. Every ending is a reopen, and a reopen costs an authorization plus whatever warm-up the feed needs, multiplied by every open stream in the fleet. So tier the bound by sensitivity rather than picking one number, vary it a little per stream so a fleet opened together does not end together, and keep it inside the life the credential authority actually gives you.
go deeper
The takeaway is simple: because a stream is authorized only at open, how long you let one response live decides how often it is authorized at all.
Be able to explain the mechanism — the emitter ends the response at the bound, the client reopens on its own, and that request is decided afresh.
Show that you cost it: reopens are not free at fleet scale, endings bunch up if every stream carries the same bound, and the bound must sit inside the credential's usable life.
Own the statement of the budget itself — a staleness number per class of feed, the reopen cost accepted for it, and a clear line between what the bound promises and what only a refused reopen delivers.
## What you are really choosing On this protocol, authorization is a single event at open and nothing re-decides it while the body runs. So the sentence a reviewer wants — *"a withdrawn entitlement stops producing data within N"* — has only one source: how long you allow one response to live. Left unbounded, N is unbounded, and a decision taken at the start of a shift is still in force at the end of it. A maximum response lifetime converts that into a number. The emitter finishes the response when the bound is reached, the client reopens by itself, and the reopen is authorized from scratch. **You get a re-authorization cadence without shipping any client behaviour at all**, which is why this is the first lever to reach for and not the last. ## The costs you are buying it with 1. **Every bound is a reopen.** One authorization decision, one new response, and whatever the feed does at the start of a stream — priming state, reading a position, warming a cache. Multiply by the number of streams open at once. 2. **A short bound turns streaming into polling.** Push the number far enough down and you have rebuilt request-per-interval, with an authorization on every interval, and lost the reason you chose a stream. 3. **A synchronised fleet ends together.** If every console opens at shift change and every response is bounded identically, they all finish and reopen within the same moment. Vary the bound per stream so the endings spread. 4. **A gap is a gap.** Each ending has a reconnect interval and whatever catch-up your feed owes; on a feed where missing an item matters, that cost is real and belongs in the same arithmetic. ## How to pick, rather than guess - **Tier by sensitivity, not by one fleet-wide constant.** A per-investigator clinical adverse-event feed and an anonymous public counter do not deserve the same number, and pretending they do means over-paying for one and under-protecting the other. - **Stay inside the credential's own usable life.** A bound longer than the life you are given produces responses whose reopen can only fail; a bound comfortably shorter makes the reopen the routine path rather than the exception. - **Decide whether the bound is your only enforcement.** If the emitting side also re-checks entitlement during the response, the bound stops being the guarantee and becomes the backstop — and the check interval becomes the number you quote instead. - **Write down what the number promises.** The honest statement is "worst case, a decision made at open stays in force for the bound", not "access is revoked within the bound" — the second is only true if the reopen is genuinely refused. - **Instrument the reopen.** A fleet where reopens suddenly fail wholesale is a credential problem, and the bound is what makes that visible on a schedule instead of at a random hour. | bound | what it costs | what it promises | |---|---|---| | none | nothing at open, everything at review time | nothing that can be stated | | hours | a reopen per stream per shift | a decision stale by at most that many hours | | minutes | reopen traffic and warm-up at fleet scale | a tight window, at the price of near-polling | | plus an emitter-side re-check | one evaluation per interval per stream | the check interval, with the bound as backstop | ## The argument to make to a reviewer The point that carries the room is that this is not a protocol setting and there is no correct value in any specification. The protocol gives you one decision per response; everything else is yours. So the deliverable is a stated staleness budget per class of feed, a bound that implements it, and the reopen cost you have accepted in exchange — with the note that tightening it further stops being free long before it stops being possible. The one option that is not on the table is refreshing an open response's authorization in place. Bounding its life is the mechanism, and choosing the bound is the judgement.
- Why not re-check entitlement on the emitting side and skip the lifetime bound entirely?You can, and it gives a tighter guarantee — but it costs one evaluation per interval per open response, and it makes the check interval the number you must defend. The bound is still worth keeping as a backstop for the case where the re-check itself is misconfigured or silently failing.
- What breaks if every stream in the fleet uses the same bound and they all opened at the same moment?They end at the same moment too, so the authorization path and the feed's start-of-stream work take the entire fleet at once, repeatedly, on a fixed period. Varying the bound per stream spreads the endings without changing what any one of them promises.
- How do you state the guarantee honestly?As a bound on staleness, not on revocation: a decision made at open stays in force for at most the response lifetime. Whether access actually stops then depends on the reopen being refused, which is a property of your authorization decision rather than of the bound.
saying these in an interview costs you the question
- Choosing one fleet-wide number without tiering by the feed's sensitivity.
- Treating a short bound as free because clients reopen by themselves.
- Claiming the bound revokes access rather than bounding a decision's staleness.
- Setting a bound longer than the credential's usable life.
- Bounding every stream identically so the whole fleet reopens at once.