A delete call on a versioned object store returned success, yet the stored bytes are still billed — what actually happened?

## What a delete call does when versioning is on There are really two different delete operations on a versioned object store, and they are distinguished by whether the caller names a version: - **A delete with no version identifier** is a *soft delete*. The store appends a **delete marker** as a new version of the key and makes it current. No bytes are removed. - **A delete that names a version identifier** is a *permanent* removal of exactly that version. Those bytes are gone, and if the version named is a delete marker, removing it un-hides the key. The same API call, with and without one parameter, is the difference between a reversible action and an irreversible one. That is the single most useful thing to be able to say about this mechanism. | Operation | What is written | What a plain read sees | Bytes freed | |---|---|---|---| | Write to an existing key | a new version, now current | the new object | no | | Delete without a version | a delete marker, now current | object not found | no | | Delete of a marker version | nothing; the marker is removed | the previous version | no | | Delete of a content version | nothing; that version is removed | unchanged, unless it was current | yes | ## Why the key disappears from listings A plain listing enumerates **current versions**, and skips any key whose current version is a delete marker. So the key vanishes from the application's view completely — this is not a filtered or greyed-out entry, it is absent. A version-aware listing, which asks the store for all versions rather than current ones, still shows the key, its marker, and every retained version beneath it. This is what makes the situation confusing in practice: an engineer checks the listing, sees nothing, and concludes the data is gone, while the storage total on the bill has not moved by a byte. Both observations are correct and both follow from the same mechanism. ## Why the bill does not move Storage is charged on what is stored, and a soft delete stores *more*, not less: - Every non-current version still holds its full object bytes and is charged for them. - The delete marker adds a small amount of metadata. It is charged as metadata rather than as object bytes, so it barely registers — but it is one more version. - Deleting the same key repeatedly stacks markers. Each call appends another one, so a retry loop against an already-deleted key quietly grows the history. The practical consequence is that 'delete everything under this prefix' is not a cost-reduction action on a versioned store. It is a visibility action. Cost only falls when versions themselves are removed. ## Undoing a soft delete Recovery is a single operation per key and needs no backup: 1. List the key's versions in a version-aware way and find the marker at the top. 2. Delete **that marker version**, by its identifier. 3. The version beneath it becomes current again, and ordinary reads and listings work exactly as before. Nothing is copied and nothing is restored — the object was never moved. This is why a soft delete is the right default for stores holding data a human can mistakenly delete: the wrong call is undone in seconds rather than recovered in hours. ## Actually removing the bytes When removal is what you genuinely want, there are two routes, and they differ in blast radius: - **Version-targeted deletes.** Enumerate versions and remove them explicitly. Precise, irreversible, and a job rather than a call for anything at scale. - **An age-based rule on non-current versions.** Configure the store so a version that has been superseded for longer than some number of days is removed automatically. This is the sustainable answer, because it bounds history growth without anyone remembering to run anything. Choosing the age is the real decision, and it is the same question as for overwrites: how long does it take this organisation to notice a wrong delete? Set the window shorter than that and the soft delete was decoration. ## The trap to name in an interview Two failure modes follow directly from the mechanism, and naming them is what separates a mechanical answer from an operating one. First, a store that gets heavy delete-and-rewrite traffic accumulates markers and versions indefinitely, so its storage cost drifts upward while the live data set stays flat. Second, a team that has convinced itself deletes are reversible may not have checked whether the caller doing the deleting can also issue version-targeted deletes — the reversibility only holds for the soft form.