Calculate the remaining request error budget.

Example Answer

A 99.9% objective permits a bad-request fraction of 0.001, so the budget for this window is 12,000 requests. The 8,400 bad requests consume 70% of that budget, leaving 3,600, or 30%.

Observed availability is 99.93%, which meets the objective for this completed window. I would not turn the remaining requests into outage minutes without a traffic model. A request-based budget depends on where and when requests arrive.

Worked reasoning

• Allowed bad requests: 12,000,000 × (1 − 0.999) = 12,000.
• Consumption: 8,400 / 12,000 = 70%.
• Remaining: 12,000 − 8,400 = 3,600.
• Good fraction: (12,000,000 − 8,400) / 12,000,000 = 99.93%.

The allowance describes this window, not a transferable credit for the next one. For a rolling window, both eligible and bad events change as data enters and expires. A time-based 99.9% objective over exactly 30 days would permit 43.2 bad minutes under its own definition, but that is a different metric and cannot be substituted here.

What the interviewer is assessing

Core checks (1 point each):

• Computes 12,000 allowed and 3,600 remaining bad requests.
• Computes 70% consumption and 99.93% availability.
• Keeps request-based and time-based objectives distinct.

Stronger (+1 after all core checks): Explains how a rolling denominator and expiring events affect the next observation.

Acceptable alternatives: Equivalent fractions or decimal notation receive full credit when units remain clear.

Red flags: Treats 99.9% as a 0.01% allowance or equates 3,600 requests with 3,600 seconds.

Follow-up

The next window has only six million requests. Is its budget still 12,000?

Example response: No. Under the same request-based objective its allowance is 6,000 bad requests. The target fraction is fixed; the event allowance scales with that window's eligible request count.