[raxxorraxor]

I think Kafka is primarily for streaming data in the first place. I use colloquial definitions, but streams are not events from my point of view. So something like activeMQ or rabbitMQ seems to be more fitting for event sourcing. Don't know the tools the author did suggest.

But I think the most important differentiation is whether you have streams or messages.

That said, the ability to roll back to a previous "state" of an event queue is pretty nice in Kafka. But if you don't want to scale ad infinitum a more common message broker might be more fitting for consuming events. I only used Kafka in an experiment, I have no in depth knowledge.

[necovek]

As you implicitly note, message queueing systems like RabbitMQ provide no persistence, and are thus unsuitable as an event store (a database).

Having an event log — the ability to "roll back" — is a crucial feature of event sourcing, so I think you misunderstood the terminology a bit.

However, I do believe it's not your fault: entire DDD terminology is trying to slap big names on already existing concepts in the interest of better/easier communication (there was "journalling" at some point, and RDBMS DBAs used to achieve similar effects with trigger-based history tables), but in my opinion, it has largely failed: people constantly confuse what each of the terms actually is, and digging yourself out of misapplied terminology is even worse.

[raxxorraxor]

Ah, the terminology is indeed completely unfamiliar to me. I didn't understand events for holding persistent data. I was thinking about event busses. I would imagine reconstructing data from a list of event is quite difficult in many circumstances.

[necovek]

If your entire application is based on event sourcing, it's usually not difficult, just slow (which is why the article talks of snapshots as well).

Of course, if you are misusing the pattern, you've got needless complexity no matter how you slice it.