During a traffic surge your rented broker refuses to create another stream at a ceiling no request lifts — what can you do that hour?

## Why the ceiling surfaced now A hard cap on a hosted broker is a ceiling the provider will not raise however you ask. Normal traffic sits well below one, so the design never exercises it. What reaches it is precisely the unusual event — a surge that spawns per-tenant channels, a replay that opens hundreds of connections, an incident response that creates a parallel stream to divert traffic onto. The cap is therefore met in the worst possible context: under load, with attention elsewhere, by the very action intended to relieve the problem. The first discipline is to stop treating it as a supply problem. Nothing you file changes the number today. The only question worth the next five minutes is which class of ceiling you are against, because the available moves are different for each. ## What the hour actually permits | ceiling class met | move that can land inside the incident | move that cannot | |---|---|---| | object counts (streams, queues, partitions) | carry the new channel on an existing stream behind a routing attribute; consolidate two low-volume channels; retire a genuinely dead stream | creating a second cluster and rebalancing the estate onto it | | connections and sessions | reduce how many connections the fleet opens — fewer instances, shared connections per process, stopping non-essential readers | re-architecting the client fleet's connection model | | single-message size | split one oversized message into several the reader reassembles, or trim fields the consumer does not use | changing how the domain represents the object | | outstanding work per subscription | acknowledge faster by shedding slow work, or add consumers so fewer messages sit outstanding at once | changing the acknowledgement design | | kept history | nothing — see below | nothing | Three of those rows share a property worth naming explicitly: they are moves **entirely on your side of the boundary**. They need no provider action, no ticket and no deployment of anything the provider owns. That is the test to apply to any suggestion made in the incident channel — if the move depends on somebody at the provider doing something, it is not an option this hour, however reasonable it sounds. ## The class with no relief The history ceiling is different in kind. Object counts, connections and outstanding work all describe things that exist right now and can be rearranged right now. The longest history a tier will keep at all describes something that has already happened: records older than that ceiling were never retained, so no action inside the incident brings them back. If the plan was "we will read from the beginning and rebuild", and the tier's ceiling on kept history is shorter than the window you need, the plan was never available. That is worth saying plainly during the incident rather than after an hour of investigation, because it redirects the response to a different source of truth. ## Why it is a redesign, not a ticket Once the incident is over, the distinction that matters is between a **workaround** and the **redesign** it is standing in for. The moves above buy time and each carries a cost: - Consolidating channels onto one stream makes every reader filter, which spends reading capacity on messages the reader discards and couples teams that were separate. - Re-keying changes how work is distributed, which on platforms that split a stream changes ordering relationships between records that used to travel together — a semantic change made under pressure. - Splitting one message into several makes the reader responsible for reassembly and for the case where one part never arrives. - Shedding readers to free connections leaves work unread, which becomes the next incident. So the follow-up work is real: decide which ceiling the estate will be designed away from, and do that deliberately. That is usually either a governance change (fewer, larger, shared streams with an owner per channel, instead of one per tenant) or an estate split (a second cluster with a defined division of which streams live where, and an asynchronous copy where both need the data). Both are weeks, which is exactly why neither is an answer at the moment the ceiling is met. ## Preventing the rediscovery The reason this question is asked at senior level is that the prevention is unglamorous and almost never done: measure your current count in each ceiling class as an ordinary operating signal, next to the ceiling, and treat the ratio as capacity like any other. A ceiling you are at eighty per cent of is not headroom — the same surge that makes you want another stream is the one that consumes the rest.