I came along a very interesting video of Martin Fowler about Event Driven Architectures and how that term covers a lot of different things: The many meanings of event driven architectures . I want to share my notes cause I think there is a lot of important info in the talk.

 

Four things related to Event Driven Systems that might be present in such a system:

1) Event Notification

Know the difference and similarities between a command and an event. A command tells someone what needs to happen. An event tells someone what event has happened.
If something happens in one Service it produces an Event.
Other Services then listen on that event.
+ Inversion of dependency: The one emitting the event does not need to know anything about the one listening to it. The listener knows an event might pop up and determines its own behavior.
+ Many other services can listen on a particular Event
– It’s hard to follow the flow of what an event initialises

 

2) Event Carrier State Transfer

Events carrying part of the state. This way you don’t have to 1) listen for an event 2) fetch the data for the event at the service that emitted the event.
+ Much less traffic
+ high availability of the interesting data
– Eventual consistency (deal with it)

3) Event Sourcing

Keeping the state of your application as a sequence of Events.
At any given moment in time it should be possible to reproduce the current state from the events that are stored.
Often snapshots of the states are regularly stored in the event database so that we can replay from there.
+ debugging (replay what went wrong)
+ replay history
– Versioning is hard
– External systems need to deal with this

 

4) CQRS

Separating the reads from the writes.
Specifically using one application / service for updates on the data.
Updating that data in a database of that service.
Reading from a separate database that is kept consistent with the first database.
+ different view on the data on read and write side
– Eventual consistency (deal with it)
– Often becomes complex