Event Sourcing : what could possibly go wrong? by Andrzej Ludwikowski

Yet another presentation about Event Sourcing? Yes and no. Event Sourcing is a really great concept. Some could say it’s a Holy Grail of the software architecture. I might agree with that, while remembering that everything comes with a price. This session is a summary of my experience with ES gathered while working on 5 different commercial products. Instead of theoretical aspects, I will focus on possible challenges with ES implementation. What could explode (very often with delayed ignition)? How and where to store events effectively? What are possible schema evolution solutions? How to achieve the highest level of scalability and live with eventual consistency? And many other interesting topics that you might face when experimenting with ES.

[@basilthomas790]

Excellent presentation and best by far PRACTICAL discussion regarding how to implement Event Sourcing that I have viewed anywhere!!

[@TheLavaBlock]

Very compact and comprehensible summary. Thank you for this

[@TheKorrent]

Really thanks for giving an overview on architecture variants and stack options! Great to have your opinion on that

[@wo11ucks]

Where can we find slides?

[@Strannik20111]

The main point I've learnt from this talk is that event sourcing is just funny)

[@omerorhan80]

what about sensetive data? for example credit card information. When we keep events they will always be readable, so isn't that a safety issue? So we shouldn't use ES for that kind of use cases?

[@user-mq9gr5zz6o]

Brilliant presentation Mate

[@sarwanhakm7517]

thank for the presentation but man how do you replay events through the event bus for a new read model or just prepare a brand new read db? this doesn't sound like an ES system to me where Dual-Write Problem is introduced that causes inconsistencies

[@KhaledKimboo4]

Every presentation ignore the elephant in the room, state consistency is crucial not because the client needs them but your commands and domain handlers requires them, I say +90% of state query (read model) are fetched by other commands to check, verify, decide... before storing the event, hence es after a while you'll be forced to implement atomic state persistency . Event sourcing is like walking on you hands to better see the floor.

[@mehrdadk.6816]

The worst thing to do is to use EventSourcing that relies on database. Imagine that you come up with 90 million events, then good luck with performance issue on start up

[@mehrdadk.6816]

@@VitoVicoVito it depends, for this case it's better to use EventSourcing and Snapshots at the same time, however this is really hard to implement. One another case is to use Kafka Streams which has internal state-store. Flushing old events after snapshot is also possible

[@casiowatch125]

See Akka persistence for an "out of the box" event sourcing+ snapshotting library. But you basically snapshot your state after x number of events. Then when rebuilding state, you take the snapshot as your base state and replay events on top of that instead of starting from the genesis event

[@casiowatch125]

Oh it's already discussed in the talk