Event Sourcing / CQRS

A good intro on how we see Event Sourcing / CQRS can be found in our blog post "Event Sourcing and CQRS". We assess these technologies as TRY, as it is an extremely valuable part of an architect's tool box, though it is no silver bullet and should only be applied to selected domains.

Also relevant is article about The Log, as this applies to event logs as well.


  • for each state mutation, the intent is recorded through an event. This is extremely valuable information, where lots of data can be extracted from lateron.
  • can be used to model complex workflows
  • can be used to archieve high scalability through creation of topic-specific / denormalized read models
  • does not hide eventual consistency from the end user


  • usually quite some boilerplate code has to be written for commands, events etc.
  • the domain must be well-understood, as modifying existing domain events is difficult
  • is eventually consistent, which is a pattern a developer is not so familiar with usually. However, eventual consistency is an extremely important property of a system; so hiding this is usually a leaky abstraction.