Your design depends on a grouping construct, but the in-memory store you are moving to offers none — what replaces it?

## What you are actually losing Before hunting for a replacement, be precise about the loss. A group promised that **no other caller's operation was applied between your steps**. It did not promise all-or-nothing, it did not offer an isolation level, and it never rolled anything back. So the thing you must replace is narrow: the window in which another caller can observe or disturb the middle of your sequence. If no reader of those entries can act on the middle state, you may need nothing at all. This matters because teams migrating between stores in this class routinely over-estimate the loss, and then build a locking scheme to replace a guarantee they never had. ## The replacements, and what each one needs | Mechanism | What it gives | What it requires | |---|---|---| | **Server-side in-place update** | The read and the change happen at the server as one operation | The server must understand the value — a counter, a map field, a collection member | | **Conditional create** | A write that happens only if the entry is absent, reporting whether it did | Nothing beyond the store offering a create-if-absent form | | **Version token** | A write refused if the entry changed since it was read | The store must hand out a token with the value | | **Submitted program** | Several steps read, decided and written at the server as one unit | The store must accept a program, and the entries must share a node | | **Expiring claim** | One caller holds the right to do the sequence for a bounded time | A conditional create plus a lifetime and an owner marker | | **One entry instead of several** | The change is a single operation, so there is no middle | The data must fit and be written whole | Two of these deserve a note about where they stop existing. **Server-side in-place update** only exists where the server can interpret the value; a large part of this class stores opaque bytes and hands them back untouched, and there every change is a full read-modify-write. **A version token** does not need that interpretation at all — it is an opaque marker — which is why it is the remedy that survives on the most restrictive store in the class. ## What has no replacement - **All-or-nothing across entries.** It was never on offer, and no combination of the mechanisms above manufactures it. If two effects must never be observed apart, that invariant belongs where rollback exists. - **A unit spanning entries that do not share a node.** Where the keyspace is split, a multi-entry unit needs the entries co-located; without that, you have separate operations and separate outcomes. - **A guarantee that the effect survives.** Applied is not persisted, and on a replicated tier it is not necessarily replicated either. ## Deciding, in order 1. **Name the reader.** Who could observe the middle state, and what would they do wrong? If the answer is nobody, stop here. 2. **Try to make it one operation.** Reshaping two entries into one value, or moving arithmetic to the server, removes the problem rather than guarding it. This is the cheapest answer and the most often skipped. 3. **If the server cannot read the value, reach for the version token** and accept a retry loop, whose behaviour under contention is its own subject. 4. **Use a conditional create for one-shot decisions** — who owns this, who was first — because it answers a race in a single call. 5. **Reach for an expiring claim last**, when the protected work genuinely spans several operations, and only with a deadline sized against that work. 6. **Push the invariant downstream** when none of the above is honest about what you need. ## Portability is the real lesson A design that says "we submit these three operations as a group" encodes an assumption about the store, not about the problem. The assumption is invisible until the day the tier changes — a different store, a hosted variant, a split keyspace — and then it surfaces as a rewrite rather than a configuration change. Writing the sequence as "these three effects must not be observed apart, and here is what a reader does if they are" keeps the requirement separable from the mechanism, which is what makes the move cheap.