"Event Streaming is not Event Sourcing!" is probably the article I'm linking the most from those that I wrote. It's part of my Don Quixote crusade to untangle those terms, as I've seen many significant architectural decisions made without realising those differences. And the consequences were severe.
There's a skewed perspective conflating #EventSourcing with #EventStreaming.
I know those terms sound similar. I know many people tell you that you can use Kafka as an event store, but...
Event Sourcing is about making decisions, capturing their outcomes (so events) and using them to make further decisions (so events are the state).
Event Streaming is about moving information from one place to another and integrating multiple components.
Event stores are databases. They may have similar capabilities as Event Streaming solutions, but the focus is different:
- event stores on consistency, durability and quality of data,
- event streaming solutions (like #Kafka) are focused on delivery, throughput and integration.
So, to give a bold comparison, saying that Kafka is an event store is almost like saying that #RabbitMQ is a database.
I really like Kafka; I've been using it successfully, along with the Event Sourcing tool. That's why I believe it's important to know the difference and how to compose those tooling instead of mixing them and getting a hangover.
Check more in my article 👇
https://event-driven.io/en/event_streaming_is_not_event_sourcing/