What does referencing instead of embedding cost you in write atomicity?

## What "atomic per document" means Every mainstream document store guarantees that a write to a single document either applies completely or not at all, and that no reader sees it half-applied. This holds however deep the change goes: you can set a top-level field, push onto a nested array and decrement a counter three levels down in one operation, and every reader sees the state either before or after, never in between. That guarantee is the quiet reason embedding is attractive. If two facts must always agree — an account balance and the ledger entry that produced it, an order's total and its line items — putting them in one document makes their agreement a property of the storage engine rather than of your code. ## What you give up when you reference Split those two facts into two documents and the single guarantee no longer spans them. Three distinct problems appear, and candidates usually name only the first. **Visible intermediate state.** Between the two writes there is a window in which one record reflects the change and the other does not. Any concurrent reader may land in that window. How bad that is depends entirely on what the reader does with it — a stale count on a dashboard is nothing, a stale entitlement check is a security bug. **Permanent drift on failure.** If the process crashes, the connection drops, or the second write is rejected, the window never closes. Nothing in the database will repair it. Unlike a transient inconsistency, this one accumulates: every failure adds a record pair that will disagree forever until something goes looking. **Interleaving.** Two concurrent operations touching the same pair can apply their writes in different orders on each side, producing a combination neither of them intended. This is not solved by retrying. ## The remedies and their price **Multi-document transactions.** Modern document stores offer them, and they genuinely restore atomicity across documents. The price is real: extra coordination latency, contention between transactions touching the same documents, limits on how long a transaction may run and how much it may change, and a substantially higher cost when the documents live on different partitions. They exist for the cases that need them, not as a replacement for a model that keeps a rule inside one document. **Idempotent, retryable second writes.** If the second write can be replayed safely, the failure mode becomes "retry until it lands" instead of "lose the update". This usually means making the write assert a target state rather than apply a delta, so replaying it changes nothing. **Ordering for a benign intermediate state.** Choose which write goes first so that the window, if observed, is harmless or self-correcting — write the authoritative record before the derived one, so a reader sees a missing derived value rather than a wrong one. **Reconstructibility plus reconciliation.** If the second document is derivable from the first, drift is repairable by a background job that recomputes it. This is the most robust answer at scale, because it survives every failure mode rather than trying to prevent them. ## Why atomicity is not a licence to embed everything The argument runs the other way too. Pulling a large relationship inside one document to get atomicity concentrates all of its write traffic on one record. Every writer now contends for the same document, so throughput on that entity is bounded by the rate at which one record can be updated, and hot entities serialise. Embedding also reintroduces every growth problem an unbounded relationship has. When the relationship is large or hot, referencing plus one of the remedies above is the correct answer even though it is the weaker guarantee. ## How to decide Ask what rule has to hold. If there is an invariant that must never be observed broken — a state machine, a balance, an approval and the thing it approves — the data it spans wants to be in one document, provided that document stays bounded and its write rate is survivable. If the relationship is merely convenient to read together, atomicity is not the deciding factor and you should choose on locality and growth instead. ## Saying it well in an interview State the guarantee precisely (one document, one write, all-or-nothing, isolated), name the three failure modes referencing introduces, price the remedies honestly, and finish with the counterweight: the same embedding that buys atomicity also buys contention and unbounded growth, so this driver is weighed against the others rather than winning outright.