# Availability Durability Consistency And Cost
Architecture tradeoffs often reduce to four questions: does it stay up, does it keep acknowledged data, what can reads observe, and what does it cost?
| Dimension | Question | Common levers |
|---|---|---|
| Availability | Can users keep using the path during failures? | Redundancy, failover, degraded modes |
| Durability | Can acknowledged writes be lost? | Replication, backups, write-ahead logs |
| Consistency | What stale/conflicting reads are allowed? | Transactions, quorums, version checks |
| Cost | What compute, storage, network, and operational cost does this require? | Tiering, caching, retention, managed services |
These dimensions are connected. Improving one can weaken another. Multi-region replication can improve availability and durability, but it increases cost and may force harder consistency decisions.
## Availability
Availability is path-specific. A product page, checkout flow, admin report, and export job do not need the same target. Good designs identify the critical paths and give them simpler dependencies.
Common tactics include health checks, load balancing, retries with timeouts, circuit breakers, regional failover, and graceful degradation. A search page may fall back to cached results. A checkout payment step may need to fail closed.
## Durability
Durability is about acknowledged writes. If the system tells the user "saved", what would it take to lose that data?
Backups alone are not enough. You need to know the recovery point objective, recovery time objective, replication mode, restore procedure, and whether restores are tested. See also [[wiki/replication]] for how copies can help or hurt.
## Consistency
Consistency defines what readers are allowed to observe. Strong consistency protects invariants but can add latency and reduce availability. Eventual consistency improves resilience but requires product handling for stale reads, duplicates, and repair.
Use [[wiki/consistency-models|consistency models]] deliberately. A profile photo can take seconds to propagate. An inventory decrement during checkout may need a stricter guarantee.
## Cost
Cost is not just the cloud bill. It includes on-call load, incident frequency, migration effort, data repair, and developer time. A cheaper service can become expensive if the team must build missing reliability around it.
Cost-aware architecture asks which paths deserve expensive guarantees. See [[wiki/cost-aware-architecture]] for the habit of matching spend to business value.
## Pattern Examples
| Pattern | Helps | Risk |
|---|---|---|
| Single-region managed database with backups | Simplicity, cost, strong local consistency | Regional outage affects availability |
| Multi-AZ database | Availability, durability | Higher cost, failover complexity |
| Async replicas for reads | Read scale, isolation | Stale reads, replica lag |
| Event log plus projections | Auditability, rebuildable views | Operational complexity, eventual consistency |
| Active-active multi-region | Regional survival | Conflict resolution, high network and ops cost |
## Failure Modes
- Claiming "high availability" while every request depends on one fragile provider.
- Replicating corrupted data and mistaking copies for recovery.
- Allowing stale reads on paths that enforce money, inventory, or permissions.
- Designing for five nines before the team can operate two nines.
- Ignoring data transfer and cross-region replication cost.
## Pro Tip
Do not optimize one dimension blindly. Five nines of availability with weak durability may still be unacceptable for money, health, legal, or audit data.
Start with the product promise. If the promise is "your uploaded tax document is safe", durability dominates. If the promise is "the public status page stays reachable", availability dominates. The design follows the promise.