3 ms·
I'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 se
by revskill 6y ago
I'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).