One of the benefits of event-sourced systems is that it's possible to take the full set of atomic events and replay them, for example, in test scenarios. System tests verify against the actual use cases that happened in production. Audit logging comes for free as well, being part of the core of the application.

This approach also enables us to change business functionality and replay some events, either to fix bugs and to correct behavior, or to apply the event information to new functionality. This makes it possible to apply new features on events as if they were part of the application since day one.

If the chef system adds functionality to continuously calculate the average time of meal preparation, the events can be redelivered to re-calculate the representations. Therefore the database contents will be reset and the events redelivered, only to the updating consumer, which results in new representation being calculated and persisted. Kafka can explicitly redeliver events.

The events, however, are solely used to update the status representations, not triggering new commands during replays. Otherwise, the system would end up in an inconsistent state. The demonstrated example realizes this by defining a dedicated Kafka consumer group for event handlers, which is not reset to redistribute events to the event handlers. Only the updating consumers re-consume the events, to recalculate the internal state representations.

The point is, that CQRS systems enable many more use cases, due to event sourcing being used. The possibilities of capturing and replaying events, as well as the contained context and history information, enable extensive scenarios.