Eventual Consistency Needs a Read Barrier

A system accepts a write, returns success, and then immediately serves a read that does not reflect it. That is a common failure mode in event-driven systems. It shows up as duplicate submissions, dashboards that look broken, and APIs that feel unreliable under load. The usual fixes are sleeps, retries, or optimistic UI. None of those define a correctness boundary. The real issue is simpler. The write path usually has a clear durability boundary. The read path often has no corresponding freshness boundary. The system knows when it accepted your write, but it often cannot say whether a given read includes it. That gap needs a mechanism. The consistency gap When writes and reads take different paths, there is a window between durable acceptance and visible state. A client appends an event to a log. The log stores it and returns success. A separate projection process later folds that event into queryable state. Reads hit the projection, not the log. A simple timeline looks like this: Clie