Two stores both guarantee that one operation on one entry is atomic - how does run-to-completion execution deliver that, and how does per-entry locking?

## Two designs, one promise Stores in this class converge on the same advertised behaviour - *one operation against one entry is applied as a whole, and no other caller observes it partway* - by two quite different routes. Knowing which route a store took is what lets you predict its behaviour under load; assuming every store took the first is the classic recitation that an interviewer is listening for. ## How run-to-completion delivers it In **one-operation-at-a-time execution**, the server runs one operation to completion before starting the next. Atomicity is then not a mechanism at all, it is an absence: there is no other operation executing that could observe or disturb an in-flight one, so nothing needs to be locked and no lock can be contended. Two things are worth stating precisely, because both are commonly overclaimed: - The serialization is of **operation execution**, not of the whole process. Stores built this way commonly use other threads for network handling, for writing copies out, or for reclaiming memory. "One operation at a time" describes the execution stream, not a thread count. - Because the schedule is the mechanism, **the model scales by clock speed, not by cores**: adding cores gives the store somewhere to put its housekeeping, but the operation stream stays one stream. ## How per-entry locking delivers it In **per-entry locking**, several worker threads pull operations and execute them concurrently. Before touching an entry, a thread takes a lock on it - and here designs vary in an important way: the lock may be on the individual entry, or on a stripe, bucket or partition of the keyspace into which many entries hash. The lock is held for the duration of that one operation and released when it ends. The delivered guarantee is identical from the caller's side. What is different is that atomicity here has a *cost* - lock acquisition and release on every operation - and a *granularity*: on a striped implementation, two callers touching two unrelated entries can still collide if those entries share a stripe. ## What actually differs | Question | Run-to-completion | Per-entry locking | |---|---|---| | What makes one operation atomic | No other operation executes during it | The entry (or its stripe) is held for its duration | | Who waits behind a long operation | Every caller, whatever entry they wanted | Callers touching that entry or its stripe | | Effect of adding cores | Operation stream stays one stream; cores go to networking and housekeeping | More operations execute at once, until they collide on one entry | | An operation touching several entries on one node | Atomic - nothing can interleave with it | Atomic only where the implementation holds every needed lock together for the operation | | Where contention becomes visible | As queueing in front of the whole server | As waiting on specific hot entries | | Cost of the guarantee itself | None - it is the schedule | Lock acquire and release on every operation | ## What does not differ The list of things both models leave to you is the same, and it is the more important half of the answer: - **Two of your operations are still two operations.** Neither model protects the span between a caller's read and its write; both will execute other callers' operations in that span. - **Neither offers an isolation level, a rollback or a save point.** The unit is the operation, and there is no transaction to open. - **Neither extends across nodes.** Atomicity is a property of one node's keyspace; where the keyspace is split, an operation spanning entries on different nodes is not one unit at all. - **Neither says anything about survival.** An operation applied atomically on a node is not, by that fact, an effect that outlives the node. ## What this means in an interview The weak answer is "the store is single-threaded, so everything is atomic" - it names one design as if it were the class, and it makes two opposite errors at once: it makes head-of-line blocking sound universal, and it makes per-entry contention invisible. The strong answer names both routes, says the guarantee they deliver is the same, and then puts the difference where it actually lives - in *who waits* and *at what granularity contention appears*, not in what a caller is promised. A useful follow-through, if you are asked which you would rather have: they are not ranked. A workload spread thinly over a very large keyspace benefits from concurrent workers; a workload that hammers a handful of entries collapses onto the same serialization either way, and then the only thing that matters is how long each individual operation takes.