Event Stream Lab

Event sourcing and CQRS explained

Event Stream Lab teaches CQRS and event sourcing through interactive lessons, an arcade game where you accept or reject commands as the aggregate, and 36 quiz questions with C# and .NET examples. It covers commands and queries, read models and projections, folding events into state, decide and evolve, optimistic concurrency, snapshots, eventual consistency, event versioning and upcasting, replays and idempotency, crypto-shredding for GDPR, and tools such as Marten, KurrentDB (formerly EventStoreDB) and Eventuous.

Frequently asked questions

What is the difference between CQRS and event sourcing?

CQRS separates the model that changes state from the model that reads it. Event sourcing stores state as an append-only sequence of events. They work well together but are independent: you can use CQRS without event sourcing.

What is a projection in event sourcing?

A projection processes events and builds a read model, such as a table or document shaped for one query. Projections can be rebuilt at any time by replaying events.

How do you handle schema changes in event-sourced systems?

Prefer additive changes such as optional fields with defaults. For breaking changes, introduce new event versions and upcast old events to the new shape when reading. Never edit stored events.

How do you delete personal data in an event store?

A common approach is crypto-shredding: encrypt personal fields with a per-person key and delete the key when erasure is requested. Another is keeping personal data out of events and referencing it instead.

Which event stores can I use with .NET?

Popular options are Marten on PostgreSQL, KurrentDB (formerly EventStoreDB) with the KurrentDB.Client package, Eventuous, or a custom append-only table with a unique stream and version index.

Progress, XP and badges are saved in your browser only.