Object storage hands you two primitives to rebuild four database guarantees

The two primitives are not independent, and that matters before any contract gets built. Conditional writes are evaluated against the object's latest state within the bucket's consistency model ^[6]. The ETag you pass in `If-Match` came from a read. If that read can be stale, the application can misjudge uniqueness or compare-and-swap state ^[7]. Strong read-after-write is the substrate; the precondition is only the check that runs on top of it.

Now map four onto two. Uniqueness becomes conditional creation on a content-derived key ^[8]. Transaction-like mutation becomes a read, a pure computation, and a conditional replacement of exactly one object ^[9]. Both have an enforcement point, because the service rejects the request when the precondition fails. The other two do not. An index is a key designed around a frequent lookup ^[10], and history is an append-only key space whose order matches the question being asked ^[11]. Nothing in the store checks whether either is true, so half the audit is enforced by the API and half by discipline ^[1].

The boundaries are where this design earns or loses. A mutation retry has to be pure, because the computation runs again against a fresh read ^[13]. An index answers only the question it was planned for ^[14]. A transaction spanning two objects cannot be assembled from per-object preconditions at all ^[16]. And contention on a single key turns CAS retries into a possible livelock ^[17], which is the failure mode that will not appear in a demo with one writer.

The part I would keep is the key layout. Inside a customer bucket the dev.to account describes a membership key for point lookup, a mutable pointer to the active configuration, immutable version objects, and append-only event objects ^[20]. Version objects and events are never rewritten, so the audit property comes from the key space rather than from an `UPDATE` path ^[21]. The pointer is the one mutable thing: deploying overwrites it, rollback moves it to an older version, and the history survives because the version objects are retained ^[22].

None of it holds without the workload. In the Ampbase case, according to that writeup, the data partitioned cleanly per organization, writes were low volume and mostly uncontended, reads were point lookups on keys the application controlled, and the interesting history was append-only by nature ^[24]. Storage selection there followed the shape of the data and the questions asked of it ^[23], and the stated motivation was avoiding a database the system did not need ^[26]. What transfers from that is the checklist rather than the saving: name your four guarantees, and if two of them cannot be expressed as a key name or a precondition, keep the database.