Event Sourcing Is Hard (2019)
As this article pops out again, I&#x27;d like to the point that although it may have some valid points, those points are not about Event Sourcing. What&#x27;s expressed in the article is the Event Streaming or Event-Driven approach. So when events are not the source of truth etc. All of the event stores that I know supports strong consistency on appends, optimistic concurrency. Many guarantee global ordering. Some help in idempotency. All of that helps to reduce those issues.
In Event Sourcing, events are the state. So the flow looks like that:<p>1. You get the events from the stream (that represents all the facts that happened for the entity),<p>2. You apply it one by one in the order of appearance to build the current state,<p>3. You run the business logic and, as a result, create the event,<p>4. You append a new event.<p>You don&#x27;t need to cache the write model state anywhere, as the state is in events. Event Sourcing has its issues and troubles, but the stuff described in the article apply to tools like Kafka, etc. They&#x27;re not tools for Event Sourcing but Event Streaming. They&#x27;re designed to move things from one place to another, not to be used as durable databases.<p>I&#x27;ve made a list of articles like that: <a href="https:&#x2F;&#x2F;github.com&#x2F;oskardudycz&#x2F;EventSourcing.NetCore#this-is-not-event-sourcing" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;oskardudycz&#x2F;EventSourcing.NetCore#this-is...</a><p>I&#x27;ll repeat it again: this is not Event Sourcing.