Availability
Availability is the share of time, or of requests, that a system serves correctly. A target of 99.9 percent allows about 43 minutes of failure in 30 days. One part without a live partner can use all of that in one fault.
See it on the board
The same traffic runs on two boards. The simulator measured both when this page was built.
| Measure | Goal | One balancer and one database copy | Two balancers and 3 database replicas |
|---|---|---|---|
| Availability | at least 99.5% | 50% Fail | 100% Pass |
| p99 latency | under 150 ms | 22 ms Pass | 33 ms Pass |
| Lost writes | none | 0 Pass | 0 Pass |
| Monthly cost | 24 USD/mo | 44 USD/mo | |
| Error rate | 50% | 0% |
Key numbers
| Number | Value |
|---|---|
| Mean time between failures, one part | 8,760 h |
| Time for a failed part to recover | 30 s |
| Time between edge health checks | 10 s |
| Price of one more load balancer | 4 USD/mo |
3 of 3 up · availability 99.9999%
How it works
Availability is often given as a number of nines. 99 percent allows about 7 hours of downtime in 30 days. 99.9 percent allows about 43 minutes, and 99.99 percent about 4 minutes. Each extra nine costs more than the one before.
A chain is only as available as all its parts together. If a request needs a balancer, a server and a database, and each one is up 99.9 percent of the time, the chain is up about 99.7 percent. Each part in series lowers the total.
Redundancy lifts the total. Two copies of a part, where either one can do the work, fail at the same time much less often than one copy fails. This works only if the copies fail apart, on separate hosts or zones, and if a health check moves traffic fast. A part with no partner is a single point of failure: one fault there stops everything.
Some parts need more than two copies. A database that waits for 2 copies on each write needs 3 replicas, so that writes continue when 1 replica fails.
In the levels you find each single point of failure and give each critical part a live partner.