skip to content

A stream idles most of the day then takes one heavy nightly burst — how does a provisioned-capacity tier bill that differently from a consumption-priced one?

level: seniorimportance: should knowfreq 47%

answer

  1. reserve ahead, or pay what flowed
  2. duty cycle decides which is dear
  3. a reservation is also a ceiling
  4. consumption pricing has no upper bound

basics

~20 s

A provisioned-capacity tier bills the pre-bought units of capacity for every hour they are held, so a peak-sized reservation is paid for all twenty-four; a consumption-priced tier bills close to nothing while idle and charges the burst in full, with no ceiling on the total.

solid answer

~50 s

The two purchase shapes meter different things. A **provisioned-capacity tier** sells pre-bought units of capacity ahead of the traffic: you size the reservation for the burst and are billed for holding that size every hour, including the idle ones, so a low duty cycle pays for capacity it never uses. It gives a predictable bill and a firm throughput ceiling, which means the burst is shaped rather than absorbed if it exceeds the reservation. A **consumption-priced tier** bills what actually flowed, so the idle hours cost little, but the burst is charged at full rate, the total has no upper bound, and dimensions like billed request counts and delivered bytes to each subscriber are metered in full. Broadly, provisioned pricing punishes spiky, low-duty-cycle traffic, and consumption pricing punishes steady high-volume traffic and record populations that are large and small. Standing lines — existing streams, retained bytes times copies — usually persist under both.

go deeper

for a junior

Know the two shapes exist: one charges for capacity you reserved whether or not you used it, the other charges for what actually flowed.

for a middle

Explain which profile each shape punishes, and why a reservation is billed for idle hours while a metered tier is not.

for a senior

Do the comparison with real numbers from the workload's duty cycle, and say what the reservation's ceiling does to a burst that exceeds it.

for a principal

Weigh a predictable bill against a lower average one for the whole paying scope, and decide what bounds an unbounded meter when something misbehaves.

## The two purchase shapes A hosted broker is sold in one of two shapes, and the shape decides which traffic profile is expensive. - A **provisioned-capacity tier** sells capacity ahead of the traffic. You buy a quantity of pre-bought capacity units and hold them; the bill tracks the hours held, not the records carried. The reservation also acts as a ceiling: traffic beyond it is shaped rather than served faster. - A **consumption-priced tier** bills what actually flowed — bytes written and delivered, billed request or operation counts — with no reservation to hold. There is no floor and, crucially, no ceiling either. Both normally keep the standing lines regardless: the streams and parts that exist, and retained bytes multiplied by the replica copies stored on nodes. ## Which profile each punishes | traffic profile | on a provisioned-capacity tier | on a consumption-priced tier | |---|---|---| | idle most hours, one heavy burst | dear: the peak-sized reservation is billed for all the idle hours too | favourable: near-nothing when quiet, the burst charged once | | steady and high volume, high duty cycle | favourable: the reservation is filled most hours, so the effective rate per byte is low | dear: every byte and operation is metered at full rate, hour after hour | | enormous populations of very small records | comparatively insulated: the reservation is a capacity, not a count | dear: an operation-metered dimension counts the calls, and the bytes are beside the point | | unpredictable or occasionally runaway | bounded: the bill cannot exceed the reservation, the traffic is shaped instead | unbounded: a misbehaving producer or a mass re-read bills in full | The useful summary: **provisioned pricing converts a capacity risk into a fixed cost, and consumption pricing converts a fixed cost into an unbounded one.** Which you prefer depends on the duty cycle of the traffic and on how much variance the paying scope can absorb. ## What the reservation is actually sized by A reservation is not sized by the burst's volume; it is sized by **how quickly you insist the burst be absorbed**. Because traffic above the reservation is shaped rather than served, the same nightly burst can be bought as a large reservation that finishes in minutes or a smaller one that finishes over hours. The questions to settle before the number is chosen: 1. Is there a deadline the burst must finish by — a downstream job, a reporting cut-off, a window before the next one starts? 2. What does the reading side do while the burst is being shaped, and is anything downstream time-sensitive? 3. How often is the peak actually reached, as against how often someone believed it would be? Size the reservation for the peak you will not wait through, and accept shaping for the rest. Sizing for the highest number anyone has ever seen is where the idle hours become expensive. ## What consumption pricing exposes you to Consumption pricing is not simply the cheap option for a bursty workload; it removes a bound. - A producer in a retry storm bills every attempt that lands. - A consumer group restarted from an old position re-reads retained history, and on a metered read dimension those bytes are billed as if they were new. - Widening fan-out multiplies delivered bytes without a single extra write. - A population of tiny records bills heavily on the operation dimension while the byte dimension stays reassuringly small. None of these is a fault of the pricing; the point is that with no reservation there is nothing to stop the bill following a mistake. Teams that choose consumption pricing generally pair it with an alert on the meters rather than on the invoice. ## Choosing, in practice The honest answer to "which is cheaper" is that it depends on the duty cycle, and you can compute it: multiply the reservation you would need by the hours in the period, and compare it against the metered volume the same period would produce. One number beats the other, and the margin tells you how much variance the choice can absorb before it flips. Two further considerations often outweigh the arithmetic. First, **predictability**: a provisioned bill is known in advance, which some organisations value more than the average saving. Second, **the ceiling**: a reservation that shapes traffic is a capacity decision disguised as a pricing decision, and it will be felt as slower absorption of exactly the burst you bought the tier for.

  • How would you compute which purchase shape is cheaper for this nightly-burst stream?
    Size the reservation you would need to absorb the burst inside its deadline, and multiply it by every hour in the billing period, idle ones included. Separately, total the metered volume the same period produces — bytes written, bytes delivered to each subscriber, and operation counts. Compare the two, and note the margin: a thin margin means a modest change in duty cycle or fan-out flips the answer.
  • Does choosing a consumption-priced tier make the bill fully proportional to useful work?
    No. It makes the bill proportional to metered activity, which includes retries, re-reads of retained history and deliveries to every subscriber — none of which is new data. The standing lines also persist: streams that exist and retained bytes multiplied by their replica copies are usually billed under both shapes. Proportionality to work is a property of the workload's discipline, not of the pricing shape.

saying these in an interview costs you the question

  • Reads consumption pricing as simply cheaper because idle hours cost nothing
  • Sizes a reservation at average throughput and treats the peak as free
  • Expects a reserved throughput ceiling to stretch for a burst rather than shape it
  • Forgets a consumption-priced bill has no upper bound when a producer misbehaves
  • Believes changing purchase shape removes the per-stream and stored-bytes lines