Derk Martin: Eventual Consistency Isn't the Problem, Your Context Is

Derk Martin from codepinion.com asserts that eventual consistency is frequently scapegoated for issues like stale data, when the actual culprit is its application in unsuitable contexts. He emphasizes that eventual consistency is “fine” and that problems arise from scenarios like “reading your own writes.” This manifests in architectures such as event sourcing and CQRS, where a client executes a command, persists an event, and then immediately queries a read model that has not yet been updated by an asynchronous projection, leading to stale data. Similarly, this issue surfaces with database replicas relying on asynchronous log shipping; a primary write followed by an immediate replica read yields inconsistent results. Martin also highlights challenges in distributed data ownership, where services using asynchronously replicated data for business logic, like credit checks, can make incorrect decisions due to stale information.

Martin argues that the core problem is a user performing an action that changes state and then immediately expecting to see that updated state reflected from an eventually consistent source. For such “read your own write” scenarios, he offers several mitigations: reading directly from the primary, waiting for replication lag, incorporating projection updates into the initial command’s completion, or employing client-side versioning and polling, or WebSockets for real-time updates. Conversely, Martin highlights areas where eventual consistency is highly effective and widely accepted, such as reporting, ETL processes, and business intelligence, where data is inherently viewed “as of” a particular point in time. He concludes that most complaints about eventual consistency are “self-inflicted,” stemming from forcing it into contexts where immediate consistency is a critical user or business requirement, rather than an inherent flaw in the pattern itself.