Projections and replay
A projection transforms recorded events into a read model. Replay rebuilds that derived data; it does not execute the original commands again.
Projection and read model
A projection contains the rules for transforming events. A read model contains the resulting data used by queries.
Changing projection logic may require a new read-model build. Rebuilding does not correct invalid domain events produced by a faulty command handler.
Replay and checkpoints
Rebuild from the relevant event history or from a valid saved state with its corresponding position.
If you delete the read model but retain a completed checkpoint, a consumer will not automatically reconstruct the missing data. Reset the position deliberately or use a separate rebuild process.
Eventual consistency
An asynchronous read model may lag behind committed events. Eventual consistency does not promise a fixed or always short delay.
Show processing status where useful, monitor lag, and define how the interface confirms a write before the read model catches up.
Reliable processing
Keep read-model updates and processing positions consistent. Where possible, commit both in the same transaction or use an explicit recovery strategy.
Handle duplicate events and isolate external side effects from rebuilds. Record projection versions and test recovery procedures.
Practical exercise
Rebuild a read model into separate storage, compare its results, and measure replay time. Test a crash between updating the data and saving progress.
Event Sourcing learning path · Previous · Next · Chronacta documentation