The business says the system must be highly available. How do you turn that into a number, and what does that number cost?

Start by making the number concrete

"Highly available" is not a requirement, it is an adjective. The first move is to restate it as permitted downtime over a window, because a percentage means nothing to a stakeholder until they see it as minutes.

per 30-day month
99%      7 h 18 m
99.9%      43 m 12 s
99.95%     21 m 36 s
99.99%      4 m 19 s
99.999%       26 s

That table changes conversations. A director who confidently asked for five nines will usually reconsider on seeing that it permits twenty-six seconds of downtime a month — less than a single unhealthy pod eviction, and far less than the time it takes a human to read an alert. The number is not the goal; the goal is a shared understanding of what the business will tolerate.

Derive the target from the cost of being down

The defensible way to pick a target is to work from what an hour of downtime costs, and to note that the cost is rarely linear. For a payments rail, thirty seconds is an incident and thirty minutes is a regulatory conversation. For an internal analytics tool, four hours on a Sunday costs nothing at all.

So ask three questions. What does the business lose per hour of outage, and does that curve have a cliff in it? Does the loss depend on when — a retailer's tolerance on Black Friday is not its tolerance in February? And is the loss recoverable — a delayed report catches up, a dropped payment authorisation does not.

An availability target that costs more to achieve than the outages it prevents is a straightforwardly bad investment, and being able to say so is a large part of what a senior candidate is being scored on here.

What each nine costs

Each additional nine tends to change the kind of engineering required, not merely its quantity.

Getting to 99% needs little more than not deploying carelessly. Getting to 99.9% needs redundancy within a zone, health checks that actually remove a bad instance, and deployments that do not drop connections. Getting to 99.99% pushes you across availability zones, and now every stateful component needs a replication and failover story, which means you are paying for a standby that does nothing most of the time. Beyond that you are into multi-region, where the constraint stops being infrastructure and becomes physics and data: synchronous cross-region replication adds latency to every write, and asynchronous replication means accepting a recovery point that is not zero.

The step that catches teams out is that the last two levels are limited by operations, not architecture. At four minutes a month, no human-in-the-loop response is fast enough. Recovery has to be automatic, which means you are funding the detection and the automation and the regular exercise of both — not just the standby capacity.

Two things the target has to account for

Your dependencies cap you. If your managed database publishes 99.95% and you have no fallback for its unavailability, you cannot credibly commit to 99.99% for anything on its path. Composed availability is the product of the independent things on the critical path, so the honest first step is to enumerate that path and multiply. Candidates who promise a number above their weakest dependency have not done the arithmetic.

Planned work counts unless you exclude it deliberately. Users experiencing a maintenance window do not feel it differently from an outage. Either put maintenance inside the budget, which is the honest choice and forces you toward zero-downtime deployment, or negotiate an explicit exclusion with the business. What you must not do is measure availability in a way that quietly discounts the downtime you caused on purpose.

Define measurement before you agree the target

An availability figure is meaningless without stating what counts as down and where it is observed from. Is a request that returns HTTP 200 with an error inside the payload a success? Is the service down when one of forty endpoints is failing, or is availability computed per endpoint and weighted? Are you measuring at the load balancer, which will look excellent while a broken CDN keeps every real user out, or from a probe outside your own network?

Teams routinely agree a number and then discover at the first incident review that they had different definitions, and the argument that follows is worse than having had no target. Fixing the definition costs an hour and it is the cheapest part of the whole exercise.

The target is not the deliverable. The deliverable is an agreement about what the business will tolerate, expressed in a number you can both measure and afford.