Availability vs Reliability vs Durability

Availability asks whether an authorized user can use the service when needed. For a request-driven API, teams often measure the fraction of valid requests that receive a good response within a window. Reliability asks whether the system performs its required function without failure under stated conditions over time. Durability asks whether data acknowledged as stored remains intact over time despite failures.

The properties overlap but are not interchangeable. An order database can be durable while the API is unavailable during a network outage. An API can be available but unreliable if it returns fast 200 responses with wrong totals. A service can fail over and remain available yet violate durability if an acknowledged order disappears.

Use one contract for the rest of the article: POST /orders with Idempotency-Key: ord-42 must create exactly one correct order, return 201, and preserve it after the database primary fails.

For POST /orders, availability is best measured from the user's boundary: good requests divided by valid requests over a stated window. Define “good” narrowly enough to match the product—perhaps 201 or a valid idempotent replay within 500 ms. Planned maintenance, dependency outages, and overload still affect the user even when the application process itself is healthy.

Redundancy improves availability only when failover works. Two API replicas behind a load balancer remove one process as a single point of failure; multi-zone database replicas can remove one zone. But every extra dependency also creates another way for the request to fail. Health checks, timeouts, load shedding, and tested failover are the mechanisms—not the number of boxes in a diagram.

A 99.9% monthly request-success SLO allows a 0.1% error budget. That budget should drive release decisions and incident response. Chasing 100% availability can cost more than the user value and can block safe changes; choose the target from the business consequence of a bad event.

Reliability adds correctness and time. The order service must calculate the right total, create the order once, and keep meeting that contract under the stated traffic, dependency, and failure conditions. A service that answers every request but sometimes double-charges is highly reachable and deeply unreliable.

For software services, one useful reliability SLI is the fraction of good events that satisfy correctness, latency, and outcome constraints. Component metrics such as mean time between failures (MTBF) and mean time to repair (MTTR) help operations, but they do not replace the user-facing contract. Ten tiny failures and one long failure can share similar downtime while producing different customer harm.

Idempotency is a reliability mechanism for retries. If the client times out after payment succeeds, it repeats POST /orders with ord-42. The server stores the key with the first result and returns that same result instead of creating a second charge.

Durability starts at the acknowledgment boundary. If the API returns 201 Created, the system has made a promise about ord-42. The exact promise depends on the storage contract: was the record only in process memory, appended to an operating-system buffer, flushed to stable storage, or replicated to another failure domain before acknowledgment?

Replication protects against device or node loss only when replicas are independent and the write policy waits for enough copies. Checksums detect corruption; repair restores redundancy. Backups and point-in-time recovery protect against operator mistakes, software bugs, and deletions that replication may copy faithfully. Replication is not a backup.

Durability is not availability. A backup archive can retain every order while restore takes hours. Conversely, an always-responsive cache can be available while losing all orders on restart. Design the acknowledgment point from the maximum acceptable data loss (RPO), then prove restore time against the recovery-time objective (RTO).

Trigger. A custom order store appends ord-42 to an in-memory buffer, returns 201, and replicates asynchronously. The primary loses power before flush or replication. Symptom: the load balancer sends the next request to a healthy standby, so availability recovers quickly, but GET /orders/ord-42 returns 404. The service is available after failover and has violated durability; because its acknowledged contract is broken, it is also unreliable.

Root mechanism. The acknowledgment boundary was ahead of the durable commit. Fast failover cannot recover bytes that never reached a surviving failure domain. Retrying without an idempotency record risks charging again, while blindly returning success hides the loss.

Recovery. Freeze automated retries for affected keys, reconcile payment-provider records against the order log, recreate only verified missing orders, and notify users where outcome is uncertain. Prevention: move acknowledgment after the chosen commit policy, persist idempotency records in the same transaction, test power-loss/failover, and continuously restore backups into an isolated environment.

Start from harm. If users cannot place orders, availability matters. If retries can double-charge or totals can be wrong, reliability/correctness matters. If acknowledged orders must survive infrastructure loss, durability matters. Most transactional systems need all three, but targets and mechanisms differ.

Write separate SLIs: good order requests / valid requests for availability; correct exactly-once outcomes / attempted logical orders for reliability; acknowledged orders retained and recoverable / acknowledged orders for durability. Add restore-test success and measured RPO/RTO because a backup that has never restored is an assumption.

Do not multiply vendor “nines” into a system guarantee. End-to-end behavior includes your configuration, code, dependencies, operations, and correlated failure domains. Set user-facing SLOs, spend error budgets deliberately, and test the specific failure each promise claims to survive.