Your write is an UPDATE guarded by a version column, and it sometimes reports zero affected rows. Walk through how you would build the retry loop around that failure: what must be redone, how many attempts, what backoff, and what would make a retry unsafe.

## What zero affected rows actually tells you An optimistic write is a compare-and-set: `UPDATE ... SET v = v + 1 WHERE id = ? AND version = ?`. The engine matched the primary key but not the version predicate, so the row exists and its version has moved on. A concurrent transaction committed between your read and your write. (If the row could also have been deleted, distinguish the two cases with a follow-up existence check, otherwise you will retry forever against a row that is gone.) The important consequence is that *every value you derived from that read is stale*, not just the version number. If you computed `newBalance = oldBalance - amount`, the `oldBalance` you used is no longer current. ## The loop wraps the unit of work, not the statement The naive fix — catch the conflict and re-run just the UPDATE — is wrong in both possible forms. Re-running it with the original version will fail again deterministically, forever. Re-running it with the freshly-read version but the previously computed value writes stale data over the winner's change, which is precisely the lost update you were defending against. So the retry boundary is: rollback (or let the transaction end), start a fresh transaction, re-read current state, re-execute the domain logic, re-issue the guarded write. Structurally that means the transactional work lives in a callable unit — a function, a command handler — and the retry decorator sits *outside* the transaction boundary, never inside it. A retry attempted inside an already-failed transaction is another classic mistake: in many engines the transaction is unusable after certain errors until it is rolled back or unwound to a savepoint. ## Attempt caps and backoff Retry is a bet that the conflict was incidental. Under low contention two attempts nearly always suffice. Under high contention the loop degenerates: N writers all redo work, one wins, N-1 retry, and the useful throughput of the row is bounded by the transaction duration while CPU burns on discarded work. Convoying is real — the losers all wake at the same instant and collide again. So: cap attempts at roughly three to five; add a small randomized (jittered) delay between attempts so competitors desynchronize; and on exhaustion return a domain-level conflict to the caller — an HTTP 409-style outcome for a user edit, or a scheduled re-enqueue for a background job. Never loop unbounded, and never sleep for long inside an open transaction, because that turns a concurrency problem into a lock-hold problem. Also decide which failures are retryable at all. Conflict signals (zero rowcount, an ORM's optimistic-lock exception, a serialization-failure or deadlock-victim error) are retryable. A constraint violation, an authorization failure, or a validation error is deterministic — retrying just wastes attempts and hides the real error. ## Making retry safe Retry is only correct if the unit of work is *replayable*. Two hazards: 1. **External side effects.** If the block sends an email, calls a payment API, or publishes a message, a retry duplicates it. Fixes: move effects after successful commit (an outbox row written in the same transaction, dispatched afterwards), or make the call idempotent using a stable key derived from the business operation rather than generated per attempt. 2. **Mutable in-memory state.** If the retried function mutates an object graph or an accumulator that survives the failed attempt, attempt two starts from corrupted state. Re-hydrate entities from the database at the start of each attempt; do not reuse the stale objects. In ORM terms this usually means a fresh persistence context per attempt, since the old one still caches the losing snapshot. ## Observability and the escape hatch Instrument conflicts per entity type. A steady conflict rate on one row is a design smell: the row is a hot spot, and the fix is usually structural — split a counter into shards and sum on read, move the contended field to its own row so unrelated edits stop colliding, or replace read-modify-write with a single relative statement (`SET qty = qty - 1 WHERE qty >= 1`) that the engine serializes internally with no application retry at all. That last option is the cleanest answer whenever the new value is a pure function of the old one, and a strong candidate to name in an interview. Finally, if conflicts stay high after those changes, switch that specific path to a short pessimistic transaction: taking the lock up front converts wasted work into a brief wait, which under heavy contention is the better trade.