Durability

## The core guarantee Durability is the D in ACID: once the engine tells the client 'committed', the transaction's effects survive a subsequent failure. The failure the classical definition has in mind is a **crash** — the process is killed, the kernel panics, the power is pulled — anything that wipes volatile memory but leaves the storage intact. After restart, the database comes back with that transaction applied. The practical implication is a rule about ordering: the engine must not acknowledge the commit until enough information to reconstruct the transaction is on stable storage. Everything else — pages still dirty in the buffer pool, the data file not yet updated — is fine, because the recorded information is sufficient to restore the state on restart. ## Why this matters to application code Durability is the boundary at which an application is allowed to tell the outside world that something happened. Before the commit returns, you must not send the confirmation email, charge the card, hand the message to another system, or return 201 Created. After it returns, you may. Systems that acknowledge to users before the commit returns will, sooner or later, tell someone their order exists when it does not. Equally important: if the commit call **fails or the connection drops**, the outcome is *unknown*, not 'failed'. The transaction may have committed on the server just as the network broke. Correct clients treat a lost commit response as indeterminate and resolve it by re-reading state or by making the operation idempotent with a client-supplied key, rather than blindly retrying and creating a duplicate. ## What the promise excludes **Media failure.** If the drive holding the data is destroyed, ACID durability says nothing. Recovery from media loss is the job of backups, redundant storage, and replicas. **Node loss.** Single-node durability means the data is on *that node's* stable storage. If the node is gone — hardware death, a terminated cloud instance, a failover to a replica — anything the replicas had not yet received is gone with it. **Logical damage.** A committed `DELETE` is durable. Durability makes mistakes permanent as reliably as it makes correct work permanent. Point-in-time recovery, not ACID, is the answer. **Anything the storage layer lies about.** If a device acknowledges a flush while data is still in a volatile write cache, the engine's promise is broken by the hardware beneath it. Enterprise-grade devices either honour flush semantics or protect their cache with a battery or capacitor. ## Durability is a spectrum, not a boolean Production systems configure a point on a scale: 1. **Buffered only** — the commit is acknowledged from memory. Fastest, loses recent commits on a crash. This is not durability; it is durability deliberately traded away. 2. **Flushed to the node's stable storage** — survives process and OS crash and power loss on that node. The classical ACID D. 3. **Acknowledged by one or more replicas** — survives losing the node entirely; the promoted replica has the transaction. 4. **Acknowledged in another failure domain** (rack, zone, region) — survives site loss, at the cost of cross-site round-trip latency on every commit. Each step up adds latency to every commit and buys a wider class of survivable failure. 'Is your system durable?' is therefore an incomplete question; 'what failures does a returned commit survive, and what is your acceptable data-loss window?' is the real one. ## Answering well Give the crisp definition first — committed effects survive crash and power loss because the record reached stable storage. Then immediately scope it: single-node by default, not media loss, not node loss unless replication is synchronous, and note that a lost commit response means unknown rather than failed. That combination separates a candidate who memorized ACID from one who has operated a database.