Should a shared ticket-intake queue be bounded, and what should enqueue report when it is full?

## The decision, stated honestly "Unbounded" is not the absence of a limit. It is the choice to let the limit be the machine's memory, discovered at runtime, at the worst possible moment, with no useful diagnostic. Every in-memory queue is bounded; the only question is whether the bound is one you chose and can talk about, or one the operating system enforces by killing the process. So the first question is not "how big?" but **"what limits arrivals?"** If tickets can only be created by a fixed number of upstream agents each holding one in flight, the depth is already bounded by something real, and adding a second, artificial ceiling buys complexity for nothing. If arrivals are driven by anything you do not control — an incident that generates ten thousand tickets in a minute, a retry loop upstream, a fan-out — then the queue has no ceiling and the process will find one for you. ## Why unbounded fails badly rather than gracefully The failure mode is what matters, not its probability. An unbounded queue whose consumer falls behind grows steadily, and nothing about the growth is visible in the queue's own behaviour: enqueue keeps succeeding, dequeue keeps returning tickets, every operation stays O(1). Memory climbs until the process dies — and it takes down every unrelated thing sharing that process, long after the actual cause (a slow downstream dependency, say) started. The signal is maximally delayed and maximally displaced from the cause. A bounded queue turns the same underlying problem into an event with a timestamp, a location and a count: "intake refused 412 tickets between 14:02 and 14:05". One of those is debuggable at three in the morning; the other is a memory graph and a guess. ## The contract on a full enqueue Once bounded, `enqueue` has an outcome it did not have before, and the shape of that outcome is the real design decision: | Contract | What the caller must do | Failure style | |---|---|---| | Return an explicit accepted/refused outcome | Inspect the result and decide | Local, visible, easy to test | | Signal a distinct queue-full condition on the error path | Handle that specific condition | Visible, but easy to swallow generically | | Accept and silently discard | Nothing — and that is the problem | Invisible data loss | The third is the one to rule out. A discarded ticket that reported success is indistinguishable from a served one at the call site, so the loss surfaces days later as a customer asking why nobody replied. If a queue may drop, dropping must be a *stated* outcome that the caller sees and that a counter records — never a side effect of a successful-looking call. Between the first two, prefer whichever the surrounding code cannot ignore by accident. A returned outcome that callers routinely discard is no better than a silent drop; a distinct error condition that everyone catches generically alongside unrelated failures is no better either. This is a judgment about the calling code you actually have, not a universal ranking. ## Picking the number Capacity is policy, so it belongs in configuration, not in a constant. Derive the starting value from the observed high-water mark under the worst burst you have measured, plus headroom for a burst you have not. Budget it in **bytes, not items** — what the ceiling protects is memory, so capacity times record size is the number that matters, and a queue of large records needs a smaller count than the same ceiling would allow for small ones. Then instrument it: current depth, high-water mark and refusal rate. Depth that never approaches the cap means the cap is doing nothing and the real risk lives elsewhere; a refusal rate that is chronically non-zero means the cap is being used as a substitute for capacity planning. ## The organisational cost, which is the actual trade This queue is a shared component. Bounding it does not merely change one implementation; it hands every calling team a new obligation — a rejection path to design, test, monitor and get right. Multiply that by twenty teams and it is a genuine cost, and the honest framing of the decision is: *unbounded concentrates the failure into one catastrophic, unowned place; bounded distributes many small, owned failures across every caller.* The second is almost always the better system and unambiguously the more expensive change. What makes it affordable is refusing to let each team invent its own answer. Ship one refusal contract, document it once, provide the counters, and — where the platform allows — a shared helper for the common handling so that twenty rejection paths are one reviewed path used twenty times. The engineering judgment here is not "bounded is correct"; it is knowing that the cap is the easy half and the rejection contract is the half that decides whether the change actually improves anything.