Can event sourcing be considered as the same architecture pattern as event logging? Right now we plan to Kafka (or Kinesis) as a pub/sub persistent event data store. We shall not be implementing any kind of snapshot/lookback feature as our business-case actually does not need it. We had thought about using Sql Server Temporal tables however decided against because of implementation details (like possible data migration issues that might possibly happen in future due to changes in the data model).

However, our architects are determined to market that we have implemented "event sourcing" following these articles.

I am not able to find a specific scholarly article where the difference between the two is clearly outlined. Can someone point me to a good article about the difference, or, perhaps explain to me if I am wrong in my thinking?

  • Essentially, what Kafka holds (for a while) is a sort of "changelog" or "event log". I don't see the point in the question. The event store is the event log. Logging events into a data store is part of the Event Sourcing architecture. Whether we use events to restore the application state or not, doesn't make the solution more or less event sourcing. It makes it more or less featured. The thing is, why are you persisting events? If the goal is IPC through messages, why not a message broker? – Laiv Jun 5 '19 at 6:50
  • 1
    An event sourced system implies that the event log is the core data structure. That the system can be extended by publishing to, or reading from that event log. If that is what your system is, great let marketing go ahead. If not tell them it is not that way, there is nothing worse than discovering that the system lied about its implementation when everything has gone wrong and all you have is the event log and no way to recover an "event sourced" system. – Kain0_0 Jun 5 '19 at 6:58
  • We needed something more than a “traditional” message broker which has real-time stream processing capabilities and speed - hence Kafka. In our scenario we don't need to track which messages were read by each consumer and only retain unread messages in queue. – Deb Jun 6 '19 at 10:10

Event Sourcing means that you build the current state of an object from a history of events.

Event Logging just means you log the events.

In order to make Event Sourcing work, you have to do a few extra things over and above just logging the events such as maintaining the order, snapshotting etc as well as creating the logic which reads in the event log and creates the object state.

In my opinion Event Sourcing never really took off. It was a neat idea that is probably too complex to implement most of the time and has its purity undermined by the need to snapshot to save disk space and processing time.

You may have a niche case where the replayability and editability of events gives you a key feature in part of your system. But it's hard to justify the complexity overhead in practice.

| improve this answer | |
  • 1
    Should note that in the event sourcing world, the core of the event sourcing architecture is an event log. That's kind of an ambiguous naming that might confuse someone new. – Milan Velebit Jun 4 '19 at 13:15
  • Actually people often use this in the command pattern to implement undo. Snapshots are simply bowing to the time space trade off. Back in the day Autocad refused to snapshot and the result was waiting for your drawing to repaint every time you zoomed once the drawing was complex enough. This is a very old idea that goes by many names. – candied_orange Jun 4 '19 at 14:57
  • I would distinguish the command pattern from event sourcing myself. If you do it all in memory you have fewer issues to solve – Ewan Jun 4 '19 at 14:59
  • @Ewan serializing being the main one. Yes there are differences but it's worth understanding the similarities before you decide the idea is dead. I've always considered the big limiting impediment to be the need to capture everything that has the ability to change your state under one pattern. That's an issue whatever you call this thing. – candied_orange Jun 4 '19 at 15:15
  • well I may be wrong about the idea being dead, obviously the OPs architect would disagree, and you are right that the command pattern (for undos etc) is very similar and definitely something that is frequently used to achieve that kind of feature. I guess for me Event Sourcing is that pattern applied to object storage on a database and is a distinct thing separate from other usages of the pattern – Ewan Jun 4 '19 at 15:21

Snapshots and Temporal Queries are by no means required to do Event Sourcing.

If you store state for your domain model as a stream of events (for your Write Model) and are projecting off of that steam (for your Read Model), you are doing Event Sourcing.

| improve this answer | |
  • But don't you think without some kind of Snapshots it becomes quite impossible (perf. & maintenance wise) to maintain the "state" of a given object over-time?? i would then indeed always at-least have Snapshots in the Event Sourcing implementation, isn't it? – Deb Jun 6 '19 at 9:39
  • Not at all. I suspect that when you say "state of a given object" you are confusing the read side (projections) with the write side (the stream/event store). You only need to the state of the stream when you are writing to that stream (processing a command), to ensure that you are not violating any business rules. Snapshots should not be used as a read model--they should only be used as an optimization that fulfills the same purpose as loading from the full stream--to validate via business logic. – Phil Sandler Jun 6 '19 at 13:36
  • Take a look at snapshotting in the CQRS FAQ. cqrs.nu/Faq. Would also recommend googling/reading Greg Young on event sourcing and CQRS. There is also a group with a lot of great discussion here: groups.google.com/forum/#!forum/dddcqrs. – Phil Sandler Jun 6 '19 at 13:37
  • Thank you for your comments and links. Indeed - I meant on the read side (sorry, I maybe have foolishly assumed it was just obvious that the 'snapshots' would indeed be relevant for the "read" side). – Deb Jun 7 '19 at 10:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.