Availability vs Reliability

An availability metric might count successful HTTP responses. A reliability objective may require a notification to be sent within five minutes, a ledger entry to balance, or a report to contain data no more than fifteen minutes old. The latter needs domain-aware measurement, not just infrastructure health.

This distinction prevents a team from optimizing the wrong thing. Returning an empty result to avoid an error may improve uptime while concealing a data pipeline failure from users and operators.

Redundant instances, health checks, and failover can keep a service reachable. Reliability also needs validation, idempotency, durable state, reconciliation, and clear behavior when data is incomplete. The more consequential the domain, the less safe it is to substitute reachability for correctness.

For a social feed, showing a slightly stale page may be an acceptable reliable behavior. For a transfer, the system should preserve the transaction intent and communicate a pending state rather than invent certainty.

Choose indicators that reflect the actual promise: successful checkout completion, p99 response time for a read path, percentage of messages delivered within a window, or freshness of a replicated dataset. Pair those indicators with a target and an error budget that guides how much risk a team can take.

Avoid one universal reliability number. Important operations usually need separate objectives because their failure costs and acceptable degradation are different.

A strong candidate identifies which data can be stale, omitted, or delayed and which cannot. Then they explain the user-facing state and the reconciliation path. This demonstrates that availability choices are business decisions with technical consequences.

Staff-level answers connect objectives to team behavior: alerts should be actionable, error budgets should influence release pace, and post-incident work should improve the exact failure signal the system failed to honor.