What is high availability? Counting nines and removing single points of failure

Still stuck on the investors’ question, “99.9% or 99.99%?”, Meera Kulkarni asks Sandeep Patil what to promise.

Sandeep pulls up last month: 22 minutes down out of the 43,200 minutes in a 30-day month, so about 99.95% up. “99.99% allows only 4.32 minutes a month,” he says. “That one outage was five times that.”

“But we have two of everything now,” says Arjun Nair, pointing at four app servers and two load balancer nodes. Sandeep draws the real wiring: one Redis node, one message broker, a database standby in the primary’s building, and one DNS provider.

Zoya Mirza asks: “What happens when that whole building goes dark?” Sandeep circles the shared parts in red. SeatJaldi had “two of everything”, yet one small failure could still switch off the sale. Which parts were really single, and how many minutes does each nine allow?

High availability means the system keeps answering when parts fail. Availability, from lesson 5, is the share of time a system is up. High availability keeps that share close to 100%.

Engineers say how close to 100% a system gets by counting nines.

Keep one line in your head: parts in a chain multiply their uptimes, so downtime piles up; spares side by side cancel it.

• In a chain, every part must be up, so small gaps add up.
• With a spare beside a part, both must fail together, so the gap nearly vanishes, unless the two share something hidden.

• You have seen this: a payments app says “Our bank partner is down”, while another pays fine. The first had one bank link, the second a spare.
• On one bad day, many unrelated apps fail together. They all leaned on one shared service.

99.99% uptime allows about 4.3 minutes of downtime in a 30-day month, and each extra nine means ten times less downtime. That month is 30 × 24 × 60 = 43,200 minutes, and 0.01% of it is 4.32.

For Shabnam, that is 4.32 minutes of darkness a month. Each nine usually costs more than the one before: more spares, in more places.

A single point of failure, from lesson 1, is one part with nothing ready to take over. You remove it by adding a spare in a separate place, so both must fail at once. “Separate” means its own power and network.

A region, such as Mumbai, holds several zones; lesson 22 showed what losing a whole region costs. For Shabnam, a zone is a second hospital building on its own power; a region is the whole city grid.

Past the phone, each box below is really two: one per zone, or one per DNS provider. Hover to see where each spare lives.

What just happened? Each single point of failure was a part everything passed through, often one nobody drew, like Shabnam’s pole. Each fix also shrinks how much one failure takes with it.

Meera’s investors also want a promise. A number written into a contract, with money back or a credit if it is missed, is no longer only a goal.

Copies are independent only if they share nothing. Many real outages come from something shared: one zone, one settings push, one DNS provider.

With each part 99.9%, a Redis pair is down 0.001 × 0.001 × 43,200 = 0.0432 minute, about 2.6 seconds a month. Five pairs in a chain: about 13 seconds. That assumes the switch to the spare takes no time. Say spotting a failure and switching takes 2 minutes: each failure then costs 2 minutes, far more than 13 seconds.

Real life breaks the “independent” part. In October 2025, one large cloud provider’s own report described a database service’s DNS record left empty by its own automation. Many of its other services looked up that name, so they and their spares failed together. The record was fixed in under three hours; full recovery took about 14.5 hours.

• Test failover, the switch to the spare. A spare you have never switched to may not start.
• A standby updated after each booking is saved can lose the last few bookings on failover. One updated before the save finishes loses none, but every write waits.
• Write down your RPO (recovery point objective): how much recent data you can lose.
• Write down your RTO (recovery time objective): how long you can be down while you switch.
• Roll changes out zone by zone, so a bad change has a blast radius of one zone.

When a seller says “designed for 99.99%”, ask whether a contract backs it.

Try it yourself

1. 1

   Draw the chain

   Write five boxes in a row: load balancer, app servers, Redis, database, message broker. Give every box except the broker a spare in a second zone.

2. 2

   Price each box

   A lone 99.9% part is down 43.2 minutes a month. A pair is down 0.001 × 0.001 × 43,200 = 0.0432 minute.

3. 3

   Add the chain

   Add the downtime of the four pairs and the lone broker.

4. 4

   Check your answer

   You are right if you get about 43.4 minutes a month, almost all of it from the lone broker. One single point of failure sets the nines for the whole chain.

Back to the red circles. Sandeep walks SeatJaldi’s wiring the way Shabnam walks the hospital, and finds four single parts.

Redis and the message broker get a spare in a second zone, the standby moves to the other zone, and a second DNS provider joins. Each spare costs money, Sandeep warns. Five lone parts in a chain would allow about 3.6 hours a month. With a spare in a second zone for each, it is under a minute on paper.

Meera now knows each nine’s price: 43.2 minutes a month at 99.9%, 4.32 at 99.99%. She still does not promise 99.99%: the paper number assumes the spares share nothing. Meera can now say how much downtime the design allows. But what counts as “up”, and how will they know they are meeting it?