Availability vs Reliability in System Design

An ordering website loads, but occasionally saves the wrong delivery address. Another website saves orders correctly whenever it responds, but is unreachable during deployments. Both have a problem, although the visible failures are different.

Availability concerns whether the service can provide the required service when needed. Reliability broadly concerns dependable correct behaviour over time under stated conditions. Teams measure these concepts in different ways. Define the user-visible success criteria instead of relying on a label alone.

A time-based indicator might count minutes during which a service is available. A request-based indicator might count valid requests completed successfully within their deadline. State the boundary, excluded traffic and observation period.

A health endpoint can answer while a database-dependent checkout fails. Measure important operations as well as component health. Fast errors or incorrect responses should not look like success merely because a connection worked.

A percentage summarises the chosen observations. It does not say when failures occurred, how many users were affected, or whether an acknowledged order was lost. Keep those consequences visible.

This model observes a 30-day month, or 43,200 minutes, and a separate sample of 1,000 requests. Change downtime minutes, failed requests and wrong responses. The request sample is illustrative and is not derived from downtime.

“Answered” counts requests that returned a response; it includes wrong responses. “Useful outcomes” subtracts both failures and wrong responses. We assume these sets do not overlap. Time availability uses only the stated downtime. These are different indicators, not universal definitions of reliability.

Redundancy means having alternatives when something fails. Two application instances can help with an instance failure, but both may still depend on one database, one network path or one shared configuration.

Separate meaningful failure boundaries where the requirement justifies it. Test how traffic moves to a healthy instance and how much capacity remains. Multiplying availability percentages is valid only under the assumed dependency and independence model; it is not a general guarantee.

Replication and backups solve different recovery needs. An accidental deletion can be copied to replicas. Backups need retention, access protection and a tested restoration process.

Recovery time objective, or RTO, is a target for how long recovery may take. Recovery point objective, or RPO, describes an acceptable data-loss window. These are goals to validate against a stated incident, not promises created by writing the acronyms.

For confirmed orders, decide whether any loss is acceptable, how users check ambiguous results and how duplicate retries are handled. Practice restore and failover with representative data, and inspect the resulting user behaviour.

Google’s availability table helps interpret time percentages; service-level guidance explains measurable objectives. Sources checked 6 October 2026. Higher targets generally need more engineering and operating effort; choose them from user needs.

A service-level indicator, or SLI, is the measured outcome. A service-level objective, or SLO, is the target over a stated window. A service-level agreement, or SLA, is a contractual commitment that may include remedies; it is not automatically identical to the internal objective.

For a time-based target over a 30-day month, 99.9% permits 43.2 minutes outside the target and 99.99% permits 4.32 minutes. For a request-based target, the budget counts unsuccessful eligible requests instead. Define exclusions and measurement before comparing percentages.

An error budget is the allowed amount of failure under the target. Track how fast it is being spent and define what happens to risky releases or reliability work when it is nearly exhausted. Do not compare a quiet midnight outage with a busy checkout outage using only a percentage that hides the affected users.

For two required independent components each available 99.9% of the time, the simplified series model gives 0.999 × 0.999 = 99.8001%. For two interchangeable independent alternatives where either is sufficient, it gives 1 − 0.001² = 99.9999%. Shared power, network, data and routing failures invalidate the independence assumption; these formulas are models rather than production promises. Read Google SRE’s objectives guidance.

Define availability and reliability through explicit observations and correct outcomes. Separate uptime, request success, data durability and recovery goals.

Plan meaningful redundancy, test restores and failover, and choose targets that match the user’s needs and the team’s operating capacity.