Four Axes
The Four Axes are a way to evaluate a deployed system by separating reliability into availability, latency, durability and cost. They turn vague demands like “make it reliable” into explicit budgets and tradeoffs, so engineers can decide what failures are acceptable, what user experience is required, what data must survive, and what the system may cost.
The problem is that “reliability” sounds like a single virtue, but deployed systems fail in different ways. An API can be reachable while returning stale data. A database can preserve every write but be unreachable during failover. A checkout path can have acceptable average latency while its slowest users time out. Without separate axes, teams optimise the wrong thing, spend heavily on unnecessary redundancy, or miss failures that users actually experience.
The Four Axes make the target measurable. Availability counts successful service over time or requests. Latency is measured as a distribution, not just an average, so tail behaviour is visible. Durability asks whether committed data survives faults, usually through replication, checksums, backups and repair. Cost is treated as a constraint, not an afterthought. Reliability then becomes an error budget: a planned amount of failure that can be spent, protected, or investigated.
The tradeoff is that improving one axis often harms another. Synchronous writes across distant regions may make data safer, but can slow every request. More replicas can tolerate instance failure, but raise compute and operational cost. Retries may hide brief faults, but can multiply load during an outage. The honest answer is usually “it depends”: on user impact, recovery time, data value, traffic shape and the price of overbuilding.
Engineers meet the Four Axes in SLOs, dashboards, deployment reviews and incident decisions. Edge proxies, load balancers and service meshes expose request failures, timeout rates and latency percentiles. Kubernetes settings such as replica counts, readiness probes and rolling updates express availability and cost choices. Storage systems advertise durability targets through replication and repair mechanisms. During planning, the axes help decide whether to ship features, reduce risk, or accept known failure modes.
Common questions
- Are availability and durability the same thing?
- No. Availability is whether the service can be used successfully now. Durability is whether data that was accepted will still exist later. A storage system can be durable but temporarily unreachable, and an API can be available while serving old or incomplete data. Treating them as one metric hides important failure modes.
- Why is latency an axis instead of just part of availability?
- Because slow success can still be user-visible failure. A request that eventually returns may be counted as available, but if it exceeds a client timeout or makes checkout unusable, the user experiences an outage. Latency should be tracked as a distribution, especially tail latency, because averages hide the slowest and often most painful requests.
- What does it mean to treat reliability as a budget?
- It means defining how much failure is acceptable, then using that allowance to guide engineering decisions. If the system is comfortably inside its budget, teams may accept more change or risk. If the budget is being consumed too quickly, work should shift towards reducing incidents, improving observability, or removing fragile dependencies.