5 ms·
This is not really a CQRS issue. This is more of a system capability around how you wish replaying events should be handled. If you design your system around i
by danielovichdk 6y ago
This is not really a CQRS issue. This is more of a system capability around how you wish replaying events should be handled.
If you design your system around idempotency you should be able to replay events and get the same result.
Not sure it was what you wnted to hear?
- revskill 6y agoI've seen replaying events as patterns on how to handle this case. But in a monothlic architecture, there's no concept as "replaying", isnt' it ? I'd love to see similar handler in a distributed environment.
- morelisp 6y agoHow do you have a distributed transaction in a monolithic architecture?
- dsies 6y agoI might be missing something - what is the issue with being able to handle a replay event stream in a monolithic service? As the previous poster mentioned, if you are are able to handle events idempotently, you should be able to ingest events, regardless of the destination - monolithic or distributed.
- revskill 6y agoI mean, is there any way other than "replay" events ? In a monothlic architecture, all events are not missed, aren't it ?
- dsies 6y agoAhhh gotcha! Yes, that's actually one, decent sized pro for doing an event driven monolith haha With that said, in a monolith - there is still a chance of missed events - deploy, bugs, etc. and at that point, you'd still want to employ replay to get your system back into a good state. Your initial question was about missed events - replay is still the answer and if you design your system with idempotency - you will be able to reingest events (even if they're dupes).