17 thoughts on “Event Sourcing You are doing it wrong by David Schmitz”

  • If eventstore documentation is awful but the community is great, how would you choose this library vs every other one out there?

  • How does GDPR deal with the requirement of storing data for fraud detection as a bank? I cannot image a customer can have his bank history forgotten to be hard deleted? Doesn't the government require an audit trail in case you are charged in court?

  • Salvatore Shiggerino says:

    Optimistic Concurrency Control is nice in a lot of places, but in this case, isn't it easier to keep the state of the whole system (or at least the subsystem that needs to be consistent) in a single thread that you submit commands to that get validated and turned into events in a fixed order that is guaranteed to be valid? As he said, it's usually neither I/O nor CPU intensive, so that single thread is going to be fast enough to deal with an awful lot of traffic.

  • Sergii Semenov says:

    First part is about Partial Ordering of events which guarantees Causal Consistency model in distributed systems. Don't think that it comes for free though.

    The ability to specify an offset on emitting events to Kafka (aka "Lamport Clocks") creates a "lock" per partition what impacts performance as you have many concurrent producers. Besides, you need to emit events for the same Aggregate into the same partition – that reduces the Availability.

    Those are the right things to do though if you want to trade the Performance and Availability in favor of Consistency. And most likely you want to do so instead of putting that complexity into the application layer. Just be aware that the approach has its price.

  • The slides from the presentation can be found here:

Leave a Reply

Your email address will not be published. Required fields are marked *