Event sourcing
On This Lesson 4 topics
This lesson is planned. The outline below lists the topics it will cover. The full lesson has not been published yet.
In this lesson
explain storing changes as facts instead of storing only the latest state.
Planned topics
- The event store is an append-only log of what happened per aggregate; current state is derived by replaying.
- You gain audit, time travel, and new read models from old history.
- You pay: event design is forever, replays take time, and fixing a wrong event is awkward.
- Not every entity needs it; use it where history is the business (ledgers, tracking).
Draft outline details
Demonstration
events for one shipment: ShipmentCreated, PickedUp, ArrivedAtHub, Delivered, stored as rows (aggregate id, version, type, payload, time); state = fold over the list. Optimistic concurrency uses the version number.
Check your understanding
Name one operational cost of event sourcing.
Show answer
Replaying long histories to rebuild state or projections, and schema evolution of stored events.
Practice
Apply this lesson with the module's lab, exercises and quiz.
Marking a lesson complete is optional and you can undo it any time. Your progress stays in this browser.