5 ms·

I re-read the article after this comment, and I would have to disagree. The article does never attempt to explain "what" recent sourcing means to them, so it's

I re-read the article after this comment, and I would have to disagree. The article does never attempt to explain "what" recent sourcing means to them, so it's hard to know for sure. However, they do mention populating state from an event log which contains meaningless events, so I have to assume they _are_ talking about event sourcing. What leads you to believe they are taking about just streaming, and not sourcing?

dm3 5y ago
They were probably also sourcing their state from the events. However most of their problems come from sharing the events between the modules/services which is not a part of Event Sourcing.
- oskar_dudycz 5y ago
  I think that they were just building the stale read models, and used them as the write model, which created the whole confusion. Regarding the sharing events between module, it's one of the most common and the most dangerous mistakes. It's a leaking abstraction that will eventually create a distributed monolith. It has only downsides of monolith and microservices, without the upsides. I wrote longer on the topic of internal and external events, and how to model them: https://event-driven.io/en/events_should_be_as_small_as_possible/ https://event-driven.io/en/events_should_be_as_small_as_poss...
  - nhumrich 5y ago
    What you are talking about is CQRS, which is a very valid pattern, and pairs well with event sourcing, but is not necessary part of event sourcing. You don't have to split your read and write models for events sourcing.
    - oskar_dudycz 5y ago
      Could you elaborate, I think that I'm missing your point.
- nhumrich 5y ago
  I am confused when you say sharing events isn't part of event sourcing. How does a service populate it's state from other services event source if it can't access it's events?
  - oskar_dudycz 5y ago
    Did you read my article that I linked, or my initial explanation of the Event Sourcing flow?
  - tomnipotent 5y ago
    > How does a service populate it's state from other services event source if it can't access it's events? Because it's the source of the events and its own system of record. If an event sourced app wants to share events, it should not be re-using internal events but creating new items intended for distribution just like you would with any other distributed system (thrift/protobuf over Kafka).
oskar_dudycz 5y ago
Could you provide an exact quote? I haven't been able to find any usage of "populate". I found: `the raw event stream subscription setup kills the ability to locally reason about the boundaries of a service.` `you have to talk to the people who will be consuming the events you produce to ensure that the events include enough data for the consuming system to make a decision` `wire a fleet of services together via an event stream` etc. Plus the drawing that's at the beginning. This clearly states that the author doesn't understand what's Event Sourcing and tells about Event Streaming. Event Streaming means: 1. Producer pushes/produces/publishes an event to the queue. In this sense, an event stream is a pipe where you put an event at the end and read it on the other side. 2. Then, you have a set of subscribers that can react to those events. The reaction may be triggering the next step of the workflow. It might also be updating the read model state. That happens with eventual consistency. You also cannot guarantee atomicity or optimistic concurrency, as tools like Kafka doesn't support it. As they were not originally built for. They let you effectively publish and subscribe to the messages. 3. Because of that, if you want to have the write model materialised from an event (or even "populated"). Then you don't have any guarantee if it's stale or not. You need to fight with out of order messages and idempotency. Thus all of those issues that are described in the article. I'm sorry to say, but the author used the wrong tool for the wrong job. If this article be titled "Event Sourcing is hard if you're confusing it with Event Streaming" then it'd be an excellent article. But, in its current shape, it's just misleading and making the wrong point, repeating just common misunderstandings. You can read more in: - https://domaincentric.net/blog/eventstoredb-vs-kafka https://domaincentric.net/blog/eventstoredb-vs-kafka - https://www.eventstore.com/event-sourcing https://www.eventstore.com/event-sourcing
- nhumrich 5y ago
  You seem to be saying that event sourcing and event streaming are mutually exclusive. In almost all cases of event sourcing I have seen, event sourcing is event streaming, but more. When you say event sourcing, where do other services source from, if there is no stream? Yes, event sourcing typically uses a database instead of a real "queue", but it still functions like a queue. You still need consumers to subscribe to events, in order to populate state, as timely as possible.

dm3 5y ago

They were probably also sourcing their state from the events. However most of their problems come from sharing the events between the modules/services which is not a part of Event Sourcing.

oskar_dudycz 5y ago
I think that they were just building the stale read models, and used them as the write model, which created the whole confusion. Regarding the sharing events between module, it's one of the most common and the most dangerous mistakes. It's a leaking abstraction that will eventually create a distributed monolith. It has only downsides of monolith and microservices, without the upsides. I wrote longer on the topic of internal and external events, and how to model them: https://event-driven.io/en/events_should_be_as_small_as_possible/ https://event-driven.io/en/events_should_be_as_small_as_poss...
- nhumrich 5y ago
  What you are talking about is CQRS, which is a very valid pattern, and pairs well with event sourcing, but is not necessary part of event sourcing. You don't have to split your read and write models for events sourcing.
  - oskar_dudycz 5y ago
    Could you elaborate, I think that I'm missing your point.
nhumrich 5y ago
I am confused when you say sharing events isn't part of event sourcing. How does a service populate it's state from other services event source if it can't access it's events?
- oskar_dudycz 5y ago
  Did you read my article that I linked, or my initial explanation of the Event Sourcing flow?
- tomnipotent 5y ago
  > How does a service populate it's state from other services event source if it can't access it's events? Because it's the source of the events and its own system of record. If an event sourced app wants to share events, it should not be re-using internal events but creating new items intended for distribution just like you would with any other distributed system (thrift/protobuf over Kafka).

oskar_dudycz 5y ago

Could you provide an exact quote? I haven't been able to find any usage of "populate". I found: `the raw event stream subscription setup kills the ability to locally reason about the boundaries of a service.` `you have to talk to the people who will be consuming the events you produce to ensure that the events include enough data for the consuming system to make a decision` `wire a fleet of services together via an event stream` etc. Plus the drawing that's at the beginning. This clearly states that the author doesn't understand what's Event Sourcing and tells about Event Streaming. Event Streaming means: 1. Producer pushes/produces/publishes an event to the queue. In this sense, an event stream is a pipe where you put an event at the end and read it on the other side. 2. Then, you have a set of subscribers that can react to those events. The reaction may be triggering the next step of the workflow. It might also be updating the read model state. That happens with eventual consistency. You also cannot guarantee atomicity or optimistic concurrency, as tools like Kafka doesn't support it. As they were not originally built for. They let you effectively publish and subscribe to the messages. 3. Because of that, if you want to have the write model materialised from an event (or even "populated"). Then you don't have any guarantee if it's stale or not. You need to fight with out of order messages and idempotency. Thus all of those issues that are described in the article. I'm sorry to say, but the author used the wrong tool for the wrong job. If this article be titled "Event Sourcing is hard if you're confusing it with Event Streaming" then it'd be an excellent article. But, in its current shape, it's just misleading and making the wrong point, repeating just common misunderstandings. You can read more in: - https://domaincentric.net/blog/eventstoredb-vs-kafka https://domaincentric.net/blog/eventstoredb-vs-kafka - https://www.eventstore.com/event-sourcing https://www.eventstore.com/event-sourcing

nhumrich 5y ago
You seem to be saying that event sourcing and event streaming are mutually exclusive. In almost all cases of event sourcing I have seen, event sourcing is event streaming, but more. When you say event sourcing, where do other services source from, if there is no stream? Yes, event sourcing typically uses a database instead of a real "queue", but it still functions like a queue. You still need consumers to subscribe to events, in order to populate state, as timely as possible.