Hello Gerard,

In fact I do agree with you and I fail to see where we disagree actually.

"I don't agree with you that event sourcing, is just storing all the events forever"

- I didn't actually make such a statement

"Event sourcing would need at least also the following two things. The first is a way to quickly build an aggregate state, based on the events that are stored. For this it's essential to have some kind of API to get all the events that belong to the aggregate."

- This is what I meant by having "ability to read a subset of those events related to a single aggregate instance (single id) in order to rehydrate your domain model"

"The second is some way to prevent concurrent writes. In a mocroservices setup, and even using Kafka consumer groups, at some point multiple instances will write to the same aggregate. You need some certain way to prevent that, otherwise the aggregate might be in an illegal state from which you can't recover in proper way."

- This is what I meant by "You want to have some mode of opt-in optimistic concurrency checking offered by that storage mechanism."

And both are covered by some event stores that are out there (also mentioned in the article).

I hope you can see the source of my confusion by your response?

Stay well