Re:Combining event sourcing and stateful systems
by withinboredom on Wednesday April 22, 2020 @06:29AM
(#22944105)
> I find this point surprising. I would say the exact opposite. I would say that pub/sub and event sourcing are two sides of the same coin: events.
I meant in the context of getting it right. I didn't experiment with all the pub/sub systems at the time, but most I experimented with would lose data in a catastrophic event and cause inconsistencies. This was several years ago though.
Re:Combining event sourcing and stateful systems
by sbellware on Wednesday April 22, 2020 @02:17PM
(#22948540)
> most I experimented with would lose data in a catastrophic event and cause inconsistencies
Fair enough. Those are probably message buses or message queues that are ephemeral transports. Since event sourcing is predicated upon permanent storage of events, there's no way to lose events that have already been committed (unless someone actually physically deletes the events).
I find this point surprising. I would say the exact opposite. I would say that pub/sub and event sourcing are two sides of the same coin: events.
> what to do if sub happens after pub
That should only ever be a problem with a non-durable transport that doesn't have serialized writes per topic. Which, admittedly, can be pretty common. But it's not so much an event sourcing or pub/sub issue as much as a choice of message transport issue.
> Concurrency. Ensuring aggregates are essentially single-threaded entities is a must. Having the same aggregate id running in multiple places can cause some really fun bugs. This usually requires a distributed lock of some sort.
Or it requires partitioning the queues and using an optimistic lock when writing (just to be on the safe side).