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?
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
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.
it is not clear how you can have an overbooked state in cinemaShow aggregate. I think the second example should be that you don't have enough funds, so then compensating action would be release the booking. if aggregate allows to overbook than this is not a case of compensating actions and/or transactions this is just lacking business constraint that makes the life easier...
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
@@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
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
Excellent presentation and best by far PRACTICAL discussion regarding how to implement Event Sourcing that I have viewed anywhere!!
Very compact and comprehensible summary. Thank you for this
Really thanks for giving an overview on architecture variants and stack options! Great to have your opinion on that
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?
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
Brilliant presentation Mate
The main point I've learnt from this talk is that event sourcing is just funny)
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.
it is not clear how you can have an overbooked state in cinemaShow aggregate. I think the second example should be that you don't have enough funds, so then compensating action would be release the booking. if aggregate allows to overbook than this is not a case of compensating actions and/or transactions this is just lacking business constraint that makes the life easier...
The whole point of Eventual consistency is to gain consistency EVENTUALY! Don't try to make it real time or even close to real time.
Software architects should be forced to write the code for their ideas. In practice I've never met an architect who can write code.
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
@@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
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
Oh it's already discussed in the talk
Where can we find slides?