5 exercises — Learn event sourcing and CQRS vocabulary: event store, projections, command handlers, and snapshots.
0 / 5 completed
1 / 5
In event sourcing, the source of truth for application state is:
Event sourcing stores every state change as an immutable event. The current state of any aggregate is derived by replaying all its events — the log IS the database, not a log of changes to a database.
2 / 5
A projection in event sourcing is:
Projections consume the event stream and build query-optimised read models (e.g., a denormalised view, a search index, an analytics aggregate). Because events are immutable, projections can always be rebuilt from scratch.
3 / 5
CQRS stands for:
CQRS separates the write model (command side: validates and processes commands, emits events) from the read model (query side: optimised projections for queries). This allows each side to be scaled and optimised independently.
4 / 5
Why do event-sourced systems use snapshots?
As aggregates accumulate events over time, replaying all events to load aggregate state becomes expensive. Snapshots store the aggregate's state at a specific event sequence number — the system replays only events after the snapshot.
5 / 5
Which sentence correctly describes the command handler in a CQRS architecture?
The command handler receives a command, loads the aggregate from the event store (replaying events or loading a snapshot), validates the command against business rules, and if valid, produces new domain events that are appended to the store.