On a rented broker tier, which ceilings will the provider not raise however you ask, and what classes do they fall into?
answer
- five classes, not one ceiling
- counts, connections, size, history
- architectural, not commercial
- scope matters: cluster or namespace
- orders of magnitude, never a figure
basics
~20 sA hosted broker's hard caps fall into five classes: how many streams or queues the cluster admits, how many partitions, how many concurrent connections and subscriptions, how large one message may be, and how long history is kept at all.
solid answer
~50 sA hard cap is a ceiling that comes from how the tier is built, not from your contract, so no raise request lifts it. On a hosted broker they cluster into five classes: **object counts** (streams or queues per cluster or namespace, and on platforms that split a stream, partitions per stream and per cluster); **connection and session counts** (concurrent client connections, concurrent subscriptions per stream); **single-message size** (the largest one message the broker accepts at all); **outstanding work** (unacknowledged or in-flight messages per subscription); and **kept history** (the longest history the tier will hold, and the largest stored bytes per stream). The class matters more than the number, because the redesign that gets you back under the ceiling differs per class — consolidate, re-key, reshape the message, shorten what you ask it to keep, or split the estate.
go deeper
Recall that a rented broker comes with ceilings, and that some of them cannot be raised by anyone. Being able to name three classes — how many streams, how big one message, how long history is kept — is already a good answer at this stage.
Explain the five classes and what each one is counted in, and say which one a given broker shape meets first. The mechanics to demonstrate are that the ceiling comes from the implementation and is enforced at the moment of use.
Show that you read a cap sheet against a stated requirement, including the scope each ceiling is counted at, and that you treat a row within an order of magnitude of your demand as already met rather than as headroom.
The trade-off you own is which ceilings the estate is allowed to depend on at all. A design that sits close to an unraisable ceiling has borrowed capacity it cannot repay, and that debt comes due during the traffic event you least want it to.
## What makes a cap hard rather than inconvenient A **hard cap** is a ceiling a hosted broker's provider will not raise however you ask, as against a soft quota a raise request can lift. It is not a commercial lever. It falls out of how the tier is built: where its metadata lives, how many tenants share a node, what one write is allowed to cost a cluster other customers are also using. That is why the honest answer to "we have hit the cap" is a design change rather than a support conversation. Two properties separate this from a negotiable number: - The figure is a **property of the implementation**, not of your agreement, so spending more does not move it. A larger purchase tier sometimes shows a higher ceiling, but only because it is a differently-built offering — the number was not negotiated, you were moved. - It is enforced **at the moment of use**. The create call is refused, the connection is rejected, the oversized message is not accepted. You meet a hard cap in production behaviour, not on a bill. ## The classes of broker ceiling Every broker shape has ceilings in all five classes; what differs is the unit each one is counted in, and which one you meet first. | class | what it bounds | where it bites hardest | |---|---|---| | object counts | streams or queues per cluster or per namespace; on platforms that split a stream, partitions per stream and per cluster | every shape, but the counted object differs | | connections and sessions | concurrent client connections, concurrent subscriptions or attached consumers per stream | designs that hold a session per attached consumer | | single-message size | the largest single message the broker will accept at all — commonly an order of hundreds of kilobytes to a few megabytes | every shape, and rarely adjustable on a rented one | | outstanding work | unacknowledged or in-flight messages per subscription, or uncommitted writes per writer | brokers that acknowledge message by message | | kept history | the longest history the tier will keep at all, and the largest stored bytes per stream | consumption-priced tiers, where storage is a metered service | The shape of the broker decides which row you meet first, and this is where most candidates generalise from the one platform they know: - On a platform that **splits a stream into partitions**, the partition count per cluster is usually met first, because every stream consumes several at once and the count is fixed when the stream is created. - On a **shared-queue** broker, where consumers compete for messages and a message is removed once acknowledged, there are no partitions to exhaust at all; the queue count and the number of messages allowed to be outstanding per subscription bite instead. - Where storage is **shared bulk storage** rather than per-node disks, object counts can be generous while connection counts or per-stream throughput are tight. - Where the tier keeps history as a metered service rather than on a volume you sized, the ceiling on how far back you may ever read is set by the tier, not by your policy. ## Why the class matters more than the number Knowing that "there is a limit" is worth nothing in a design review. Knowing the class tells you which move is even applicable: consolidating several logical channels onto fewer streams, re-keying so the same work spreads across fewer partitions, reshaping or splitting an oversized message, asking the tier to keep less, or splitting the estate over more than one cluster. Those are five different projects with five different lead times, and only one of them will be the one you need. ## Reading a cap sheet against a requirement 1. Write down what your design demands in each class: streams today and in two years, connections per instance multiplied by instances, the largest message the domain can legitimately produce, the furthest back anyone will ever need to read. 2. Find the tier's ceiling for each, and record its **scope** — per cluster, per namespace, per stream, per connection, per paying scope. The same number scoped per namespace is a completely different design from the same number scoped per cluster. 3. Mark each row raisable or not. Only the rows nothing lifts belong in this analysis; the rest is ordinary capacity planning. 4. Treat any row where your design sits within an order of magnitude of the ceiling as already met. Growth, retries, and the fan-out of an incident eat that margin in an afternoon. Reason in orders of magnitude rather than in figures. A specific number belongs to one offering on one day; the shape of the problem — which class, at what scope, raisable or not — survives the offering, the day, and the choice of product.
- Why does the scope a ceiling is counted at change the design as much as the number does?A ceiling counted per cluster is a shared budget every team spends from, so governance and consolidation become the answer. The same number counted per namespace or per paying scope is spent per team, so the answer is to create another one. Before you plan around a ceiling you have to know which of your units it divides.
- If a ceiling turns out to be raisable after all, does it belong in this analysis?No. A ceiling the provider will lift on request is ordinary capacity work with a lead time. Only the ceilings nothing lifts force the design, and mixing the two produces a plan that quietly depends on a favour. Establish which kind each row is before you build the argument on it.
- Why is the single-message size ceiling the one operators most often discover late?Ordinary traffic sits orders of magnitude below it, so the design never exercises it. The message that reaches it is unusual by construction — a bulk import, a document with an attachment, a retry that batched several items together — and it arrives long after the tier was chosen.
Renting a broker tier is like renting a workshop unit. The landlord will rearrange the furniture, fix the wiring and even add power — but the doorway height is in the building, not in the lease. You bring smaller furniture, you assemble it inside, or you rent a different unit.
saying these in an interview costs you the question
- Says every ceiling on a rented broker can be raised by asking
- Treats message size and stream count as the same kind of problem
- Assumes a partition-count ceiling exists on every broker shape
- Believes a larger purchase tier lifts every ceiling proportionally
- Confuses a ceiling the provider enforces with one you set on clients
- Quotes a ceiling as a figure without naming its scope