Menu
When snapshots of aggregates became out of sync with event log i can simply replay my events from early snapshots (which supposed to be in sync). The same i can do when i add/remove new fields or when i modify logic of existing handlers.
In case i need to add new read model (i.e. new report view) i can do the same again - i will replay my events.
But how should i handle situation, when read model became out of sync with the event log? Storing of events and publishing are in one transaction, but updating of read model occurred in another transaction, which can fail. Repeating events from the very beginning can help, but it can take eternity. Do i need a concept of snapshots for the whole read model?
How do you solve this problem? Thank you.
310
CQRS is a popular architecture pattern because it addresses a common problem to most enterprise applications. Separating write behavior from read behavior, which the essence of the CQRS architectural pattern, provides stability and scalability to enterprise applications while also improving overall performance.
Instead of saving latest status of data into database, Event Sourcing pattern offers to save all events into database with sequential ordered of data events. This events database called event store. Instead of updating the status of a data record, it append each change to a sequential list of events.
In a CQRS context, one benefit of Event Sourcing is that the same events can be used to notify other components — in particular, to notify the read model. The read model uses the events to create a snapshot of the current state, which is more efficient for queries. However, Event Sourcing adds complexity to the design.
Indeed, Event Sourcing shines the most when we can work with the business to find the business events. Event Storming and Event Modeling proved that events work great as a way to describe business processes. We can use them as “checkpoints” of our workflow. Events are also essential as a data model.
What would be the reason for failure in event handler? How long is "eternity"?
Read model updates rarely fail (unlike command handlers), since the logic inside is extremely simple. Failures are likely to be caused by transient problems (IO/network outage) and would be handled automatically by the message bus.
However, if read model became corrupted for some reason, then the easiest way to reset it and to stream events through. Even millions of events would take reasonably small amount of time. Plus, you can always use Map-Reduce approach.
I would recommend against introducing snapshots to read models. I think this just complicates the architecture without any significant gains.
96
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
