Event Sourcing Cheat Sheet

Updated 2026-08-01

🧠Study flashcards on this topic95 cards · spaced repetition→

Event Sourcing is an architectural pattern where state changes are stored as a sequence of immutable events rather than overwriting current state in a database. Born from Domain-Driven Design and financial ledger systems, this pattern treats events as the single source of truth, allowing complete audit trails and the ability to reconstruct any past state by replaying the event log. Unlike traditional CRUD systems that lose historical context with each update, Event Sourcing preserves every state transition as an append-only log, enabling powerful capabilities like time-travel queries, retroactive corrections, and temporal analysis that are difficult or impossible with conventional persistence. It pairs naturally with CQRS, since the same event log that rebuilds write-side state can also feed read-side projections, though the two patterns can be adopted independently. The key mental model is simple: instead of storing where you are, store how you got there. Every event is a fact that cannot be changed, only compensated for or refined with new events.

What This Cheat Sheet Covers

This topic spans 11 focused tables and 121 indexed concepts, 95 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Core ConceptsTable 2: Event Store DesignTable 3: Event Replay and ReconstructionTable 4: Projections and Read ModelsTable 5: Event Versioning and Schema EvolutionTable 6: Sagas and CompensationTable 7: Event Store OptimizationTable 8: Production PatternsTable 9: Testing and DebuggingTable 10: Integration and FrameworksTable 11: Advanced Patterns

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

Table 1: Core Concepts

Start here—these are the building blocks every event-sourced system is assembled from, and the rest of the cheat sheet assumes you know them. The mental model worth holding onto: commands ask for a change, aggregates decide whether it's allowed and emit events, those events get appended to a stream, and projections fold them back into shapes you can actually query.

Concept	Example	Description
Event Store	`events.append(OrderPlaced)` `events.append(OrderShipped)`	• Append-only database that stores every state change as an immutable event • serves as the single source of truth for the system
Aggregate	`class Order:` `def place(self):` `return OrderPlaced(...)`	• Domain entity that enforces business rules and produces events • reconstructed by replaying its event stream • the rule of thumb: one aggregate, one stream, one transaction
Event	`OrderPlaced(orderId, customerId, items, timestamp)`	• Immutable record of a past action written in past tense • contains all data needed to describe what happened • the atomic unit of state change
Command	`PlaceOrderCommand(customerId, items)`	• Request to perform an action that triggers business logic • validated against current state • produces zero or more events if successful
Event Replay	`state = reduce(events, apply, initial)`	• Process of rebuilding aggregate state from scratch by sequentially applying all historical events • enables time-travel and state reconstruction
Projection	`def on_OrderPlaced(event):` `db.orders.insert(...)`	• Read model built by processing events to answer specific queries • typically eventually consistent • optimized for read performance not writes
Snapshot	`if event_count > 1000:` `save_snapshot(state)`	• Cached aggregate state at a point in time to avoid replaying thousands of events • optimization that doesn't affect correctness
Stream	`stream_id = f"Order-{order_id}"` `events = store.read(stream_id)`	• Ordered sequence of events for one aggregate instance • maintains causality • each stream has a unique identifier tied to a business entity
EventStorming	`Orange sticky note: "OrderPlaced"` `-- notes placed left-to-right on a timeline`	• Workshop technique for discovering a domain's events collaboratively with sticky notes • surfaces the event vocabulary and stream boundaries before any code is written
Append-Only Log	`INSERT INTO events (...values)` `-- No UPDATE or DELETE`	• Storage model where new records are only added, never modified • events are immutable facts • ensures complete audit trail and temporal integrity
Temporal Query	`state_at = replay_until(timestamp)` `balance = get_balance("2026-03-15")`	• Ability to query system state at any point in history by replaying events up to that moment • enables regulatory compliance and forensic analysis

Table 2: Event Store Design

How you lay out the append-only log determines almost everything downstream—concurrency safety, replay speed, and whether you can scale past one node. These patterns cover the choices that matter when picking or building a store: versioning streams for safe concurrent writes, ordering events globally for subscriptions, grouping streams by type for cross-instance reads, and where snapshots and archived events actually live, whether you reach for a purpose-built engine like KurrentDB or adapt PostgreSQL.

Pattern	Example	Description
Stream Versioning	`UNIQUE (stream_id, version)` `expected_version = 42`	• Optimistic concurrency control using monotonic version numbers • prevents conflicting writes • reject append if stream changed since read

The rest of this section is part of the full cheat sheet

Table 3: Event Replay and Reconstruction

Replay is the heart of event sourcing—you rebuild current state by folding every historical event back over an empty starting point. These techniques keep that fast and correct as streams grow into the thousands: snapshots to skip ahead, upcasting to read old event shapes, lazy and parallel loading to stay within memory, and point-in-time replay to answer "what did this look like back then?"

Technique	Example	Description
Left Fold	`state = events.reduce(apply_event, {})` `-- or foldl(apply, initial, events)`	• Functional pattern for rebuilding state by applying each event sequentially to accumulator • idiomatic in functional languages • ensures deterministic replay

The rest of this section is part of the full cheat sheet

Table 4: Projections and Read Models

The event log is great for writing but terrible for querying, so projections turn that stream into purpose-built read models—one shape per question your UI or reports need to answer. The key tension running through these rows is synchronous versus asynchronous updates: do you keep the read model strongly consistent inside the write transaction, or let it lag for the freedom to scale, rebuild, and evolve it independently.

Pattern	Example	Description
Synchronous Projection	`@event_handler` `def on_event(event):` `update_read_model(event)`	• Projection updated within same transaction as event write • strongly consistent • read model always reflects latest committed events

The rest of this section is part of the full cheat sheet

Table 1: Core Concepts

Concept	Example	Description
Event Store	`events.append(OrderPlaced)` `events.append(OrderShipped)`	• Append-only database that stores every state change as an immutable event • serves as the single source of truth for the system
Aggregate	`class Order:` `def place(self):` `return OrderPlaced(...)`	• Domain entity that enforces business rules and produces events • reconstructed by replaying its event stream • the rule of thumb: one aggregate, one stream, one transaction
Event	`OrderPlaced(orderId, customerId, items, timestamp)`	• Immutable record of a past action written in past tense • contains all data needed to describe what happened • the atomic unit of state change
Command	`PlaceOrderCommand(customerId, items)`	• Request to perform an action that triggers business logic • validated against current state • produces zero or more events if successful
Event Replay	`state = reduce(events, apply, initial)`	• Process of rebuilding aggregate state from scratch by sequentially applying all historical events • enables time-travel and state reconstruction
Projection	`def on_OrderPlaced(event):` `db.orders.insert(...)`	• Read model built by processing events to answer specific queries • typically eventually consistent • optimized for read performance not writes
Snapshot	`if event_count > 1000:` `save_snapshot(state)`	• Cached aggregate state at a point in time to avoid replaying thousands of events • optimization that doesn't affect correctness
Stream	`stream_id = f"Order-{order_id}"` `events = store.read(stream_id)`	• Ordered sequence of events for one aggregate instance • maintains causality • each stream has a unique identifier tied to a business entity
EventStorming	`Orange sticky note: "OrderPlaced"` `-- notes placed left-to-right on a timeline`	• Workshop technique for discovering a domain's events collaboratively with sticky notes • surfaces the event vocabulary and stream boundaries before any code is written
Append-Only Log	`INSERT INTO events (...values)` `-- No UPDATE or DELETE`	• Storage model where new records are only added, never modified • events are immutable facts • ensures complete audit trail and temporal integrity
Temporal Query	`state_at = replay_until(timestamp)` `balance = get_balance("2026-03-15")`	• Ability to query system state at any point in history by replaying events up to that moment • enables regulatory compliance and forensic analysis

Table 2: Event Store Design

Pattern	Example	Description
Stream Versioning	`UNIQUE (stream_id, version)` `expected_version = 42`	• Optimistic concurrency control using monotonic version numbers • prevents conflicting writes • reject append if stream changed since read

Table 3: Event Replay and Reconstruction

Technique	Example	Description
Left Fold	`state = events.reduce(apply_event, {})` `-- or foldl(apply, initial, events)`	• Functional pattern for rebuilding state by applying each event sequentially to accumulator • idiomatic in functional languages • ensures deterministic replay

Table 4: Projections and Read Models

Pattern	Example	Description
Synchronous Projection	`@event_handler` `def on_event(event):` `update_read_model(event)`	• Projection updated within same transaction as event write • strongly consistent • read model always reflects latest committed events