Event Sourcing: Why Kafka Is Not Suitable as an Event Store (opens in new tab)

(medium.com)

2 pointsleftshift3y ago4 comments

4 comments

3 comments · 1 top-level

raxxorraxor3y ago· 2 in thread

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.

necovek3y ago

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.

raxxorraxor3y ago

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.

1 more reply

j / k navigate · click thread line to collapse