6 ms·
> Pub/sub in Event Sourcing is a bad idea I find this point surprising. I would say the exact opposite. I would say that pub/sub and event sourcing are two sid
by sbellware 6y ago
> Pub/sub in Event Sourcing is a bad idea
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).
- withinboredom 6y ago> 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.
- sbellware 6y ago> 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).