Infeasibility Proof

A brief asks for 99.99% availability and a 4-hour maintenance window every month. Both numbers were reviewed. Neither reviewer did the one calculation that matters: 99.99% permits about 53 minutes of unavailability a year, and 12 maintenance windows of 4 hours is 2880 minutes — roughly 54 times the budget.

No design resolves that. There is no architecture, no vendor and no amount of engineering that makes the two lines compatible, so the correct deliverable is not a design but the sum. Producing it takes five minutes and it changes the conversation from "how will you build this" to "which of these two is the requirement", with the person who wrote the brief making that call.

The practice generalises. Requirements are almost always validated one at a time against the proposed system and never against each other, because each arrives from a different stakeholder in a different unit. An infeasibility proof puts every stated requirement into one common unit — minutes per year, milliseconds per request, bytes per day, money per month — and looks for the pair that cannot both hold.

Why it matters

The alternative is discovering the contradiction after the design has been committed. By then a quarter has been spent, the conflict is resolved by whoever is in the room, and the record shows an engineering failure rather than a requirements one. Finding it in week one costs an afternoon; finding it in month six costs the design.

It also changes the architect's standing. A brief returned with "this is hard" is an opinion and will be overruled. A brief returned with "these two lines differ by a factor of 54, here is the arithmetic, which do you want" is not arguable, and it hands the choice back to the person who owns it.

Implementation patterns

• One unit per dimension, written at the top of the requirements document. Availability as minutes per year, not nines. Recovery objectives as minutes. Latency as milliseconds at a stated percentile. Cost as money per month per unit of business volume.
• Check the known-conflicting pairs first: availability budget against planned maintenance; zero data loss against a latency budget smaller than the replication round trip; a recovery point objective shorter than the backup interval; a retention period against a deletion right with no crypto-shredding; a throughput target against a single-writer design.
• Show the arithmetic in three lines, with the inputs named. A proof nobody can follow is an assertion.
• Separate impossible from expensive. A pair that can both hold with a second region and a different storage engine is a price, not a contradiction, and should be returned as a price.
• Record the resolution in the brief, so the next reader sees the 4-hour window was cut to 30 minutes rather than quietly ignored.

Industry example

The arithmetic that makes this unavoidable is physical and public. A coast-to-coast round trip in the United States is roughly 60 to 80 ms, and propagation in fibre costs about 1 ms per 100 km each way. A brief specifying zero data loss across regions and a p99 of 150 ms has therefore spent half its budget before any application code runs, which can be shown in one line. At a 300-engineer enterprise software vendor a platform brief containing both lines was returned in 2 days with that calculation, and came back with the data-loss requirement scoped to a single region and an asynchronous cross-region copy carrying a stated 30-second recovery point. The brief had been reviewed by four people in 2024 and none of them had put the two numbers in the same unit, which is the normal case rather than an unusual lapse — and the design that shipped to production was the one the business chose, not the one the engineers guessed at.

Failure scenarios

• The proof is right and lands as an accusation. Delivered as "your requirements are impossible" it creates an enemy; delivered as "here are the two numbers, which do you want" it creates a decision.
• A false proof from a wrong input — a mean where the requirement is a percentile, or an availability figure that excludes planned maintenance by definition. One wrong proof costs the credibility to deliver the next one.
• Impossible mistaken for expensive. Declaring infeasible what is merely a second region and 40% more spend will be overturned the moment a vendor arrives with a quote.
• The contradiction resolved verbally and never written down, so it returns next planning round with the original numbers.

Trade-offs

The practice is nearly free and its cost is social: it makes visible a conflict stakeholders were comfortably ignoring, often one between two executives' commitments. Some of those were being managed deliberately, and forcing them open early can stall a programme that would otherwise have proceeded and quietly dropped a requirement later.

Against that, the information arrives when it is cheap to act on. Prefer early arithmetic unless the programme's funding genuinely depends on both numbers appearing in the document, in which case say so privately and record it.

When not to use it

Where the requirement set is small and obviously compatible, this is ceremony. Where the numbers are genuinely unknown — an early-stage product with no traffic and no contract — there is nothing to check, and inventing inputs to produce a proof is worse than waiting.

Do not use it as a refusal mechanism. An architect who returns every brief with an impossibility calculation is routed around within two quarters. The proof is for the two or three genuinely contradictory pairs per programme; everything else is a design problem.

Interview question

Q: A sponsor hands you a brief with a 99.95% availability target, a 15-minute recovery point objective and nightly backups as the stated backup strategy. They want a design in a week. What do you deliver?

What a strong answer covers: the arithmetic that a nightly backup gives a recovery point of up to 24 hours, which is about 96 times the stated 15 minutes, so the pair is contradictory before any design exists · that 99.95% allows roughly 4.4 hours of downtime a year, which is a separate and compatible number · delivering the contradiction as a choice with prices attached — continuous archiving or replication to meet 15 minutes, or a revised objective — rather than as a complaint · and recording whichever is chosen in the brief with the date and the owner, so it is not re-litigated next quarter.

Quick check

Quiz: A brief requires 99.99% availability and one 4-hour maintenance window a month. What do you return? The sum: 53 minutes of annual budget against 2880 minutes of planned windows, a factor of roughly 54, so the pair is impossible and the sponsor must choose which number is real.

Flashcard: What is the common unit trick behind an infeasibility proof? — Put every requirement into one unit — minutes per year, milliseconds per request, bytes per day — and look for the pair that cannot both hold.