Deferrability Window

A lending platform rated four capabilities for availability and gave the top tier to onboarding, because onboarding carried the most traffic. Eight months later a four-hour incident starting at noon took out the disbursement run, the 15:30 payment-rail cut-off was missed, and a day of customer loans settled a day late. Onboarding had been protected at roughly £140k a year; disbursement, which had no slack at all, was in the tier below.

The mistake was ranking by how many people notice an outage rather than by what an outage destroys. Deferrability is the distinction: work that can be done later needs somewhere to wait, and work that cannot be done later needs to not stop. The window is the measured gap between the earliest moment the work can start and the moment its value expires.

Why it matters

Availability spend is finite and tiering decisions are made once, usually early, usually from intuition. Traffic and visibility are the intuitive signals and both are wrong, because they measure attention rather than loss.

The window converts the argument into arithmetic. Onboarding at 900 applications a day has a window of days: applicants return, the queue drains, the loss is a few percent of conversion. Disbursement has a window that varies by hour and reaches zero at 15:30, because the clock belongs to the payment rail and not to you. Those are different engineering problems and they should not receive the same answer.

It also changes what you buy. A capability with a long window is made resilient with durable intake and replay, which is cheap. A capability with a short window needs redundancy ahead of the deadline, which is expensive. Spending redundancy money on a deferrable capability is the most common way an availability budget is wasted.

Implementation patterns

• Measure it per capability and per hour of day. A single number hides the shape. Disbursement has nine hours of slack at 06:00 and none at 15:00.
• Classify by whether the clock is yours. External clocks — settlement cut-offs, regulatory submission deadlines, market opens, broadcast schedules, delivery promises with a refund attached — produce short windows that no amount of internal process change can lengthen.
• Deferrable capabilities get durable intake. Accept, persist, acknowledge, process when healthy. An outage becomes latency, and the recovery objective can be generous.
• Short-window capabilities get the deadline moved first. Scheduling the disbursement run at 13:00 instead of 15:10 buys more resilience than a second data centre and costs nothing. Do this before buying redundancy.
• Record the window in the service catalogue next to the tier, so the tier has a reason attached and can be challenged when the business changes.
• Re-measure when commercial terms change. A promise of a decision within 60 seconds converts onboarding from a days-long window to a seconds-long one overnight, with no code change to signal it.

Industry example

Regulated payment deadlines make this concrete. India's unified payments infrastructure, live since 2016, settles continuously while the underlying interbank obligations close at published times, so an operator on it has a window that shuts at a fixed hour regardless of how its own systems are feeling. A retailer's end-of-day reconciliation has a window of hours; a marketing email has a window of days. The same company runs all three on one platform and routinely protects them identically, which means it has over-bought for two and under-bought for one.

The pattern also appears in live broadcast. A platform carrying a scheduled sporting final has a window of zero for the duration of the event and a very long one either side, which is why continuity plans written in recovery-time terms fail at exactly the moment they are needed.

Failure scenarios

• An outage window that straddles the deadline. Nothing alerts, because availability over the day looks fine. The loss is discovered by the operations team the next morning.
• Redundancy that activates too late. A failover taking 20 minutes is useless for a run scheduled 10 minutes before the cut-off.
• Queue depth treated as the health signal for short-window work. The queue is healthy; the clock is not.
• A hidden window created by a sales promise, where support discovers the obligation before architecture does.
• Catch-up capacity never sized. Deferred work must be processed in addition to the normal day's volume, and a 4-hour backlog on a system running at 70% utilisation takes far longer than 4 hours to clear.

Trade-offs

Measuring the window costs a conversation with the business owner and some care about hour-of-day effects. The main hazard is treating it as fixed: it is a property of the commercial promise, not of the code.

When not to use it

Skip the exercise when every capability in scope has the same clock, which is true in some narrow systems — a trading venue, a real-time bidding stack — where everything is short-window by construction and the tiering decision is already made. It is also unnecessary below a certain size: with three services and one team, the tier is whatever the team can actually operate, and a formal measure adds process without changing anything.

Do not use it as the sole input either. A capability with a long window but a severe reputational or safety consequence — a clinical alert, a fraud block — is protected because of the consequence, not the clock.

Interview question

Q: You have budget to put exactly one of four capabilities into the highest availability tier. One carries ten times the traffic of the others. How do you decide, and what would make you change the answer six months later?

What a strong answer covers: ranking by what unavailability destroys rather than by traffic; identifying which clocks are external; naming the cheap move of shifting a deadline before buying redundancy; sizing the catch-up capacity for deferrable work; and recognising that a new commercial promise can shorten a window without any code change, so the tier needs a review trigger tied to contract changes.

Quick check

Quiz: A batch run must reach a payment rail by a 15:30 cut-off and currently starts at 15:10. What is the cheapest availability improvement available? Move the run earlier — slack before the deadline is worth more than a failover that takes longer than the slack.

Flashcard: Which number decides whether a capability needs redundancy or only a queue? — The deferrability window: the time its work can wait before the value is destroyed rather than delayed. Long window means durable intake and replay; near-zero window means redundancy ahead of the deadline.