Mistakes we made adopting event sourcing and how we recovered

Re:Mistakes we made adopting event sourcing and how we recov... by UK-AL on Monday July 01, 2019 @04:21PM (#20329340)

You certainly can drive activities from events in event sourcing applications. Having built many like this. You don't have to, but you can.

Just make sure services that perform actions based on events, and the services that rebuild current state based on events are different. So you replay the state building without the activities being performed.

[ Parent | on HN ]

Re:Mistakes we made adopting event sourcing and how we recov... by hinkley on Monday July 01, 2019 @05:56PM (#20330142)

Also it's good if you go very very conservative on having actions generate other events.

Since event systems are frequently meant to scale up, and tend to process events in the order of receipt, they will tolerate ('hide' might be more accurate) a percentage of all events occurring in an infinite loop before anyone even thinks to notice. Discovery phase on this sort of regression can be embarrassing, to say the least.

Due to delegation and composition it's easy for this to sneak up on you. And always, always, attach some sort of origin ID (eg, correlation ID) that follows all generated events through the system. Because trying to come up with repro cases will be hard enough without having to divine where the problem comes into the system.

[ Parent | on HN ]

Re:Mistakes we made adopting event sourcing and how we recov... by groestl on Tuesday July 02, 2019 @02:14AM (#20332595)

I'm curious, do you have valid examples for generating events? I'm sceptical of allowing this as well.

[ Parent | on HN ]

Re:Mistakes we made adopting event sourcing and how we recov... by UK-AL on Tuesday July 02, 2019 @03:19PM (#20338469)

Most actions on events don't generate others events.

They tend to be things like email customer.

[ Parent | on HN ]