Durability vs Availability

## Two promises that get quoted as one An object store makes two separate promises about what you put in it, and they are measured in different units. **Durability** is about the bytes surviving. It is the store's estimate of the probability that an object it has acknowledged can still be reconstructed later. It is defended by keeping more than one copy of the object and by repairing or re-creating copies when the media or the machine under them is lost. Providers publish it as a figure with many nines, stated per object over a period. **Availability** is about the bytes being reachable. It is the fraction of time the store's request path answers your reads and writes successfully. It is defended by redundancy in front of the data: request handlers, name resolution, the network between you and the store, and whatever routes a key to a copy. The published number is always much weaker than the durability one. | Axis | Durability | Availability | | --- | --- | --- | | The question it answers | Will the object still exist later? | Can I read or write it at this moment? | | Unit | Probability of losing an object over a period | Fraction of time requests succeed | | Defended by | The number and spread of copies, plus repair | Redundancy of the request path, retries, a second path | | Broken when | No copy of the object can be reconstructed | Requests error or time out although the bytes are intact | | Your lever | The replication scope you choose | What your client does while the endpoint refuses | ## Why an outage does not move the durability number During an incident that makes the endpoint refuse requests, very little is happening to your objects. The media still holds them, the copies still exist, the repair process still runs. What failed is the path: the front end that terminates your connection, the component that resolves a key to a copy, or the plumbing between you and them. When service returns, your reads return the same bytes as before. That is why answering an outage question with a durability figure is the classic stumble - the two failures have almost nothing in common, and a store can be strong on one and weak on the other at the same time. The converse is worth saying out loud too. Being reachable says nothing about surviving: a store that answers every request promptly may still be keeping a single copy of each object in one failure domain. ## What this means for a raw-event landing zone Take the common shape where an ingest process writes raw events into an object store all day and nightly jobs read them back. An hour of failed writes is an availability event, and every decision it forces sits on the writing side: - **What happens to events the process has already accepted.** They are in your memory or on your local disk, not in the store, so no store promise covers them at all. Buffering them, or leaving them unacknowledged in the upstream queue, is what turns the hour into a stall instead of a hole in the day. - **How long you can stall.** The backlog you can absorb is bounded by your buffer and by the upstream retention, not by the store's nines. - **Whether the nightly job still runs.** If reachability returns before the job starts, the outage costs nothing downstream. None of those is informed by the durability figure. The reverse case is a genuine durability claim: if a nightly job cannot find an object that ingest was told had been written, that is worth investigating as loss - starting with whether the write was really acknowledged, because an unacknowledged write is outside the promise. ## Where confusing the two costs you - Reporting an outage to stakeholders as data loss when nothing was lost. - Starting a recovery that was never needed because reads were failing. - Sizing no client-side buffer, on the grounds that the store is described as extremely reliable. - Assuming a many-nines durability figure implies copies in more than one place, when the spread of copies is a separate setting with its own price. ## How to answer it out loud 1. Name both properties and their units in one sentence each. 2. Say which one the scenario attacks: failed requests are an availability event, and the stored bytes are not the thing at risk. 3. Put the remedy where it belongs - in the client that buffers and retries, not in a storage setting - and add the honest caveat that neither promise defends against a bad write of your own, which is a third thing again.