Burst Capacity

A workload with a stable floor and violent peaks has two different capacity problems. The floor is predictable and continuous, so it rewards the cheapest possible unit cost — which usually means owned or committed capacity. The peak is unpredictable and brief, so it rewards the shortest possible lead time — which means on-demand cloud capacity, at a premium.

Burst capacity is the deliberate decision to satisfy those with different mechanisms, and to make the boundary between them a routing decision rather than a migration.

Why it matters

The framing of "cloud or own hardware" as a single decision is what makes it hard. Split by demand curve and it becomes straightforward: the baseline optimises cost, the peak optimises response time, and the architecture's job is to let capacity be selected by health and latency rather than by ownership.

The constraint most teams under-weight is lead time, not unit cost. Owned capacity is cheap and takes months to acquire; cloud capacity is expensive and available now. When demand grows by an order of magnitude in weeks, no procurement process responds, and unit-cost comparisons are irrelevant.

Implementation patterns

• Capacity as a fungible pool. Routing selects a node by health, latency and load — not by which facility owns it. Anything that hard-codes the distinction makes the mix impossible to shift.
• The burst path continuously exercised, carrying a small fraction of normal traffic rather than being held in reserve. A path first used during a surge is a path that does not work.
• Data locality planned. Bursting compute is easy; bursting the data it needs is not. Workloads that can burst are those whose data is either small, cacheable, or already replicated.
• Cost attribution per burst event, so the trade between holding more baseline and bursting more often can be evaluated with numbers.
• Geographic expansion via burst capacity first, converting to owned capacity only where sustained volume justifies the lead time and commitment.

Industry example

A real-time conferencing platform is the sharpest case. Media relaying is bandwidth-dominated and latency-critical, and its baseline is stable enough that public-cloud egress pricing for sustained volume becomes the dominant business expense — an argument for owning capacity.

But the same platform once grew roughly thirtyfold in ten weeks. No forecast and no procurement process responds to that, and owned-only would have meant simply not serving the demand. The workable answer is both: owned capacity sized to the predictable floor with margin, cloud for burst and for reaching new geographies quickly, and media routing that treats a relay as a relay regardless of who owns the rack.

The same structure appears in rendering platforms, batch analytics, CI fleets, and any workload where a steady baseline coexists with short violent peaks.

Failure scenarios

• The unexercised burst path, which fails on first use under maximum pressure.
• Baseline sized to the peak, paying for idle owned capacity all year.
• Baseline sized to the average, so bursting is continuous and the premium becomes the normal cost.
• Data gravity ignored — compute bursts successfully and then waits on data transfer, so the capacity produces no throughput.
• Burst capacity assumed available. During a broad regional demand event, on-demand capacity in a popular region may simply not be there. Reservations exist for a reason.

Trade-offs

Hybrid capacity buys the cost profile of ownership with the response time of cloud, and costs two operating models, two sets of tooling and a permanent architectural constraint that workloads must be portable between them. That portability requirement is not free — it discourages using the deepest provider-specific services on the burstable path.

For workloads whose peaks are modest or whose baseline is small, one mechanism is simpler and better. The hybrid earns its complexity when the baseline is large enough that unit cost matters and the peaks are large enough that lead time matters.

Interview question

"Your traffic has a stable daily baseline and occasional five-minute spikes at ten times that level. Walk me through autoscaling, pre-provisioned capacity, serverless, queueing and hybrid burst — and tell me what you would measure to choose."