I've been studying architecture lately, and came across the terms Event Sourcing, Event Streaming and Historical Modeling, all of them referring to "append-only" models, but all the concepts I've read so far are a little bit too abstract to me to fully understand the pros and cons of each one.

I've gone through several articles from Greg Young, Martin Fowler and some other people talking about CQRS on highly-concurrent systems and these append-only models, but so far I haven't seen a concrete implementation of a fairly complex system that would benefit from Event Sourcing, specially systems where Consistency is a first-class requirement, such as payment systems.

So, the question is, in what kind of problem could benefit from an append-only model ? Does anybody have a real-world example to present ?

  • 1
    Downvoter, care to explain how can I make the question better, or why it's not appropriate ?
    – Machado
    Dec 1, 2016 at 13:18
  • 1
    possibly this was voted down based on this meta guidance: Why do 'some examples' and 'list of things' questions get closed?
    – gnat
    Dec 1, 2016 at 13:32
  • @gnat, so a better way to ask the question would be the contrary, propose a model and ask if an append-only approach is correct for that model ?
    – Machado
    Dec 1, 2016 at 13:47

1 Answer 1


Classic (and probably the ones easiest to understand) problems for append-only are logging or monitoring systems.

In case there are hundreds or thousands of sensors pumping data into your systems, you usually won't update existing values - you just append. This saves you a lot of headaches in regard to when and how to lock your database rows, how to distribute your data and so on.

As a result, you'll get a fairly long stream of events, and you may use this in order to create different views on this data sets. One system might want to visualize the error rate (how many errors are in the logs), one system may want to visualize the request rate or most frequent requests or a complete different, probably not-yet-known aspect.

Which brings me to the second usecase: When you've got your event stream, you can always reconstruct any specific point in time based on the events.

Payment transaction systems also do (somehow) event sourcing, they are modeling all the transactions which lead to the current state of your account. If you just have your usual account table and the balance is 20 €, that doesn't tell you much. If you have a transaction (=event) log which tells you +10 €, -20€, +30€, you can always recreate the state at any point in time. Plus, you may roll back unwanted transactions or events.

  • 5
    Strictly speaking, you can never roll back an unwanted event. You can compensate for it (which is another event that you append to your stream), but you can never remove it.
    – mgw854
    Dec 1, 2016 at 14:37

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.