tezvyn:

Data Durability vs. Availability: Lost vs. Unreachable

AI-drafted, machine-checkedSource: docs.cloud.google.comintermediate

Availability is "can I reach my data right now?" while durability is "will my data still exist tomorrow?". Cloud storage systems are designed for both, but they solve different problems: network outages vs. data corruption.

WHY IT EXISTS: These terms were created to distinguish between two critical but different promises a storage system makes. One is about uptime (can you access it?), the other is about preservation (is it still there and correct?). Confusing them leads to flawed system design and misinterpreting service level agreements (SLAs).

THE MENTAL MODEL: Availability is about reachability. If a server is offline or the network is down, the data is unavailable. Durability is about data integrity. If a disk corrupts or a disaster destroys the only copy, the data is not durable—it's lost forever. An analogy is a library book: it can be durable (in perfect condition) but unavailable (checked out by someone else), or available (on the shelf) but not durable (pages are ripped out).

HOW IT WORKS: High availability is achieved through redundant access paths, like multiple servers behind a load balancer and redundant network links. If one server fails, another takes over. High durability is achieved through redundant data copies. Systems store multiple copies of your data, often with checksums to detect corruption, and spread these copies across different physical disks or even geographically separate data centers.

WHEN TO USE IT: Use these concepts to evaluate SLAs for any storage service. A system with 99.99% availability promises very little downtime per year. A system with 99.999999999% (eleven 9s) durability promises an extremely low probability of ever losing a file. For critical data, you need strong guarantees for both.

WHEN NOT TO USE IT: Don't use the terms interchangeably. A temporary network outage affects availability, not durability. Likewise, accidentally deleting your own file is a user error, not a failure of the system's durability promise. The concepts are less distinct for systems without long-term state, like a stateless API gateway.

ONE CANONICAL EXAMPLE: Amazon S3 Standard storage is designed for 99.99% availability and 99.999999999% (11 nines) durability. This means you can expect up to 52 minutes of downtime per year (availability). For durability, if you store 10 million objects, you can on average expect to lose a single object once every 10,000 years. The system is almost certain to never lose your data, but it might be temporarily unreachable.

Read the original → docs.cloud.google.com

Get five bites like this every day.

Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.