Skip to content

Delay Budget Table

A planning artifact — instantiates Coupling Latency and Time-Delay Effects

Allocates a single end-to-end delay allowance across the stages that consume it and names an owner for each, so "too slow" becomes a per-stage budget someone is accountable for.

A Delay Budget Table starts from a total delay the coupled system can tolerate and divides it across the stages that spend time, assigning each stage a maximum allowance and a named owner. What makes it this mechanism and not its siblings is that it is prescriptive and additive: unlike a scorecard, which measures what latency is, the budget table declares what each segment is allowed to be so the parts sum to a whole that fits. Its defining move is conservation — every millisecond handed to one stage is a millisecond taken from another — which forces the trade-offs into the open and gives each owner a bound they can be held to.

Example

A web team commits that a product page must render for the user within ≈800 ms. That number is the budget, and the table spends it: DNS + TLS ≈100 ms, CDN edge ≈50 ms, the API gateway ≈80 ms, the product service ≈150 ms, a third-party pricing call ≈200 ms, the database ≈120 ms, leaving ≈100 ms of headroom. Each row names the team that owns the stage. Laid out this way, two facts jump out that a raw measurement wouldn't frame: the third-party pricing call, at 200 ms, is eating a quarter of the whole budget for one dependency the team doesn't control, and there is almost no headroom left for retries. The table converts a vague "the page is slow" into a specific negotiation — either the pricing call gets a tighter contract, or another stage must give up its share — and each stage's allowance becomes a threshold whose breach the owner must explain.

How it works

  • Set the total from the outside in. The end-to-end allowance comes from what the coupling can tolerate — how fast the target state changes, what the user or downstream unit will accept — not from summing what stages happen to take.
  • Allocate down the chain, with headroom reserved. Distribute the total across stages, deliberately leaving slack for variance and retries rather than spending every unit.
  • Name an owner per row. Each segment's allowance belongs to a specific team or component, so a breach has an address.
  • Make each allowance a live threshold. A stage that exceeds its budget is flagged; the table is the reference an alert or review checks against.

Tuning parameters

  • Total-budget tightness — how aggressively the end-to-end allowance is set. Tighter forces optimization but leaves no room for the tail; looser is safe but tolerates sprawl.
  • Headroom reserve — how much of the total is left unallocated. More absorbs jitter and retries; less squeezes more useful work into the same envelope at the cost of fragility.
  • Allocation basis — equal shares, proportional to current spend, or proportional to what each stage can realistically hit. The basis decides who feels the squeeze.
  • Breach semantics — whether exceeding a row logs, alerts, or blocks. Stricter enforces the budget but risks false alarms on normal variance.

When it helps, and when it misleads

Its strength is accountability through conservation: because the parts must sum to a fixed whole, the table exposes the stage eating an unfair share, forces an explicit trade when one stage wants more, and gives every owner a bound they can design against. It is the artifact that turns an end-to-end latency goal into distributed, owned commitments — a latency budget in the engineering sense.[^budget]

Its failure modes come from the budget diverging from reality. A budget set once and never revisited becomes fiction as the system and its dependencies change, and allowances chosen politically rather than from what stages can actually achieve just relocate the blame. Summed budgets also quietly assume stages are independent and additive, which hides the correlated tail where several stages run slow together. The discipline is to reconcile the budget against measured latency (from a scorecard) on a cadence, allocate from achievable numbers rather than round ones, and budget for the tail, not just the average.

How it implements the components

The table fills the two allocation-and-bound components a budgeting artifact produces:

  • timing_chain_map — its rows enumerate the stages that consume time and their sequence, forming the chain the total is spent across.
  • delay_bounded_escalation_threshold — each stage's allowance is a delay bound whose breach is meant to flag and escalate to that stage's owner.

It does not measure the latency each stage actually spends (latency_profile) — that's the Decision Latency Scorecard — and it does not commit the total to an external party with consequences (latency_drift_monitor against a service contract), which is the Latency SLO or SLA's role.