1

Imagine system A broadcasts an event E that is of interest to system B. As a result of E, B generates its own event E' that also gets broadcast. Should E' contain inside it the event that triggered it (i.e. E) in case it becomes useful at later date to comprehend what action(s) led to the creation of E'?

And if it's not always useful, could there be a number of scenarios where it is handy to keep track of the history of an event?

Thanks in advance!

PD: I realise you could extend this argument further and end up with very heavy events (or even infinitely large if your message flow describes a cycle). Consider just keeping an identifier for the immediate originating event in this scenario.

edu
  • 428
  • 2
  • 10

1 Answers1

0

I will give an answer based on my own experience so far. If it differs from your own experience I'd like to hear it please!

While an interesting concept, events containing their preceding events are impractical. Russian doll-like events hinder the evolution of their schemas by tying them together.

If event E' contained its predecessor event E, any (non-backward compatible) change to the schema of E would necessarily require a change in the containing schema of E'. Imagine applying that restriction over a chain of events!

Ease of evolution seems key to event driven architectures and there would be little benefit of separating applications into different deployables only to tie them up again by the schemas of the events they produce.

Again, while theoretically interesting, I have found no business case for doing so either, I've usually had to forward information relevant to the chain of events like a client id, an order id or similar, but never the full event. A randomly generated artificial id (in the sense that it has no business meaning) that lives throughout the events chain has been useful for debugging/monitoring purposes (e.g. to find out how far an event has made it through the ecosystem).

edu
  • 428
  • 2
  • 10