Eventual Consistency: Handling Race Conditions in Event-Driven Systems

Eventual consistency creates real user-facing problems if you do not design for them explicitly. The most common is read-your-own-writes: a user places an order, gets a success response, navigates to their order list, and the order is not there — the write went to the primary database, but the order list reads from a CQRS projection that has not yet processed the event.

Fixing the read-your-own-writes problem:

• The simplest fix: don't re-query after a write; return the written data directly from the POST response so the user's browser has fresh data without hitting a potentially stale read model
• For operations that take longer, return HTTP 202 Accepted with a Location header pointing to a status endpoint, letting the client poll until processing completes
• Optimistic UI patterns show the expected end state immediately and correct only if the event processing reveals an error

Concurrent modifications:

• Two services updating the same entity simultaneously can cause the "last writer wins" problem where one state transition is silently lost
• @Version optimistic locking in JPA detects conflicts: if two transactions read version 3 and both try to save version 4, one gets OptimisticLockException and must retry
• This is cheaper than pessimistic locking for read-heavy systems and prevents silent data loss from concurrent saga participants

Cache invalidation under async propagation:

• TTL-based expiration doesn't work well with event-driven updates — an event changed state 200ms ago, but the cache TTL is 60 seconds
• The fix is event-driven cache invalidation: subscribe to the same events that update the read model and invalidate relevant cache entries when the event arrives

I recommend the diagnostic rule: if the problem is intermittent and resolves after a few seconds, it's propagation delay; if the problem produces permanently wrong state, it's a concurrent modification issue — they require different fixes.