EventStore: Projections, CQRS & When It Fits
Projections: Read Models Built From Events
Raw event streams aren't always convenient to query directly. A projection processes events into a derived read model shaped for efficient querying -- a core piece of CQRS-style architectures, where the event stream stays the write-side source of truth.
Eventual Consistency
A projection is built asynchronously, so there can be a small delay between an event being appended and the projection reflecting it -- a real UI/UX consideration in event-sourced systems (a read immediately after a write might briefly not show the change yet).
Rebuilding a Flawed Projection
If a projection's logic changes or has a bug, it can be discarded and rebuilt correctly by replaying the entire immutable event history through corrected logic -- a recovery capability a current-state-only system fundamentally lacks.
Event Schema Versioning
Old events remain immutable and were written against whatever schema existed at the time. A long-lived system needs a strategy (upcasting, versioned event types) so consumers correctly interpret events across multiple historical schema versions, not just the latest one.
When Event Sourcing Fits
Event sourcing pays off for domains genuinely needing a full audit trail, temporal queries ("what was true at time X"), or business processes that naturally map to a sequence of meaningful events -- it adds real complexity (event modeling, projections, eventual consistency) that isn't justified for every application.
Keep your own version of these notes — editable, searchable, and organised by your stack.
Start free