I'm growing my understanding of event sourcing. My understanding is that it provides a means of recording events as they happen so that given a common beginning state and an audit log of recorded events, the events can be replayed to achieve the same final state.

I know that sometimes events are triggered by other events. When I consider a system as a whole, I imagine that some events will be triggered externally by inputs from the user or another external source and that other events will be triggered and processed internally as side effects. I am calling the former originating events and the latter secondary events.

Originating events trigger a domino effect of secondary events. Since secondary events hinge directly on some originating event, should secondary events be recorded as part of the audit?

If you're aware of some source that discusses this in depth please cite.

  • 1
    I'm not sure that I can give a good answer to the question because I don't have a grasp of the rest of your architecture. What I can give you is a link to these two Martin Fowler articles. They helped me with understanding the Event Sourced CQRS systems I have worked on. martinfowler.com/bliki/CQRS.html martinfowler.com/eaaDev/EventSourcing.html
    – Klee
    Commented Oct 22, 2014 at 2:48

2 Answers 2


I think you're mixing up event sourcing and command sourcing. There is crucial difference between them. With command sourcing, you register external commands, like user inputs. In event sourcing, you register effects of those commands, i.e. what you've called secondary events.

In practice, you should choose either command or event sourcing and stick to it, not combining these 2 approaches. As for which one to choose, it seems that industry consensus is skewing towards event sourcing. For example, in Akka, the Akka Persistence module is based on event sourcing.

Main idea behind choosing event sourcing over command sourcing is that former allows for idempotency. I.e. however many times you replay the effects of your operation, your system would end up in the same state, while with command sourcing you're trying to rely on a fact that same command executed at different time would produce the same effect, which is, needless to say, is incautious.


From a purely practical perspective, if you include events that are triggered by other events in your log, there are two consequences:

  • If you need to replay the log, these events will be automatically triggered anyway, so you'll need a way of filtering them out
  • If you later determine that the logic that generates some such events is incorrect, and therefore decide to rebuild your system by replaying all events to remove data corrupted by the bug, the log will still contain incorrect data

From this perspective, it seems clear that at the very least such events should be logged separately rather than together with externally sourced events.

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.