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, 2019 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, 2019 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, 2019 at 10:10

2 Answers 2


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.

  • 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. Jun 4, 2019 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. Jun 4, 2019 at 14:57
  • 1
    sounds like a good solution for board game mechanics, but not sure I would call it "event sourcing" even if it's functionally identical.
    – Ewan
    Jun 4, 2019 at 16:37
  • 1
    I am accepting this reply for now as an answer since as I understand that it depends indeed entirely on the use-case of the scenario since if indeed there is no business need for replayability and editability (like say a ledger-account like scenario) then indeed its hard to justify the need of Event Sourcing. Also the concept of a bounded-context is I think more important for even thinking of using Event Sourcing. Even I am surprised that I cant find any great source-article talking about this scenario and describing or advising when to use what, and more, importantly when not-to-use.
    – Deb
    Jun 6, 2019 at 9:36
  • 1
    I think this answer is generally correct, but snapshotting is not required to do event sourcing (I don't know a single practitioner who thinks it is). Regarding the statement that ES is "probably too complex to implement most of the time" (emphasis mine)--I generally agree. Event sourcing is one tool in your tool belt, and should be used when the complexity of the problem warrants it. Jun 6, 2019 at 13:53

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.

  • 1
    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, 2019 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. Jun 6, 2019 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. Jun 6, 2019 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, 2019 at 10:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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