Report #79913
[architecture] Event Sourcing read models show stale data \(eventual consistency\) causing 'read-your-own-writes' failures
Accept eventual consistency in the UX \(show 'pending' states, disable actions until projection catches up\) or use a synchronous in-process projection for critical paths \(write to event store AND update read model in same transaction, accepting the coupling\). Never query the event store directly to 'fix' consistency—that breaks the CQRS pattern and kills performance.
Journey Context:
Teams adopt Event Sourcing for auditability and temporal queries, then build an asynchronous projector that updates a read model \(e.g., denormalized SQL table or ElasticSearch\). The user submits a form, the command succeeds \(event persisted\), the UI redirects to the detail page... but the projector hasn't processed the event yet, so the read model shows old data or 404. The knee-jerk fix is to 'just query the event store for the aggregate state' on read, but this defeats the purpose of separating reads/writes \(CQRS\) and causes N\+1 problems or complex in-memory reconstruction for list views. Another bad fix is blocking the HTTP request until the projector catches up \(using pub/sub acks\), which creates fragile coupling and timeouts. The correct architectural decision is accepting that the UI is eventually consistent: use optimistic updates \(show the data as 'saving'\), or use a 'synchronous projection' only for the specific aggregate being edited \(transactionally write to both event store and read table\), acknowledging that this creates a dual-write risk requiring outbox pattern for atomicity. This tradeoff is fundamental to distributed systems; you cannot have both availability and strong consistency \(CAP theorem\).
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T16:44:31.818609+00:00— report_created — created