Durability

Durability is the guarantee that once the system tells you a write succeeded, that data will survive, even through crashes, power loss, disk failure, or a datacenter going dark. The one-line definition: committed means it will not be lost. It is the "D" in ACID and a property interviewers expect you to address for anything that stores important data.

Durability Is Not Availability

These are often confused. Availability is whether the system is reachable right now. Durability is whether your data survives. A database can be temporarily down (not available) but perfectly durable, so that when it comes back, every acknowledged write is still there. You design for them with different techniques, and you should say which one you mean.

How Durability Is Achieved

• Persist before acknowledging: write to non-volatile storage (disk or SSD), not just RAM, before telling the client the write succeeded. Data that lives only in memory dies with the process.

• Write-ahead log (WAL): before applying a change, append the intent to a sequential log and flush it to disk (fsync). If the process crashes mid-operation, recovery replays the log. This is how most databases get both durability and speed.

• Replication: copy each write to multiple nodes before acknowledging (a write quorum), so the failure of one node or disk loses nothing.

• Multi-AZ and multi-region: place replicas in different availability zones or regions to survive the loss of an entire datacenter.

• Backups and snapshots: point-in-time copies that protect against corruption, bad deploys, human error, and ransomware. Replication alone does not protect you here, because it faithfully copies the mistake to every replica.

• Checksums and erasure coding: detect silent bit rot and rebuild lost data from parity.

Durability in Numbers

Providers quote durability as nines, just like availability but for data loss. For example, Amazon S3 advertises eleven nines of durability (99.999999999%), achieved by redundantly storing each object across many devices and multiple availability zones. That means if you store ten million objects, you would expect to lose one roughly once every ten thousand years.

The Core Tradeoff: Durability vs Latency and Throughput

Stronger durability costs write performance, and this is the tradeoff to name in the interview.

• Calling fsync on every write is the most durable but the slowest. Databases use group commit (batching many writes into one flush) to trade a tiny risk window for much higher throughput.

• Asynchronous replication acknowledges the write as soon as the leader has it, which is fast, but if the leader dies before replicating, those recent writes are lost. Synchronous replication waits for replicas to confirm, which is durable but slower.

RPO and RTO

Two targets frame your durability and recovery plan. RPO (Recovery Point Objective) is how much data you can afford to lose, measured in time (for example, at most 5 minutes of writes). RTO (Recovery Time Objective) is how quickly you must be back up. Your durability choices set the RPO: synchronous replication targets an RPO near zero, while asynchronous replication or hourly backups mean a larger RPO.

Common Mistakes

• Assuming replication is a substitute for backups. It is not; it replicates corruption and deletions too.

• Acknowledging a write before it is actually persisted, which silently loses data on a crash.

• Ignoring the RPO gap on asynchronous replicas and being surprised by data loss after a failover.

• Having backups that are never restore-tested, so you discover on the worst day that they do not work.

Interview Soundbite

"For the critical data, the write path is: append to the write-ahead log and fsync, replicate synchronously to a quorum, then acknowledge, giving an RPO near zero. I will also take regular snapshots to separate storage and test restores, because replication protects against hardware failure but not against corruption or a bad deploy. Note this is about surviving data loss, which is separate from the availability and failover design."