Notes on Event-Driven Architecture by Martin Fowler
There are 4 patterns that people call their system “event-driven” if at least one of those patterns is in place.
I just watch this great video and want to take a short note here.
Pattern 1: Event Notification
Generic service notifies specific service by events for example customer management service fire event, and insurance quoting service subscript the event. Generic service doesn’t need to know any specific service.
Pros: decoupling the receiver from the sender
Cons: hard to debug, cannot see what is going across system (cannot trust the paper written)
Extra: when to use events or commands?
- events, when you don’t care what will happen, without expecting any particular response
- commands, when you care something needs to happen, telling some service what to do
Pattern 2: Event-carried State Transfer
To prevent subscribers ask for additional information after an event occurred. All necessary data is given in the events. Subscribers store the copy they need.
Pros: reduce network traffic, availability, performance
Get Ciizo’s stories in your inbox
Join Medium for free to get updates from this writer.
Cons: replicated data, inconsistency (eventual consistency)
Pattern 3: Event Sourcing
Event Sourcing is like version control (Git) or accounting ledgers. Ability to rebuild the full state of the system by a persistent of events. Can store only it effectively as were all events, can be every single change or certain snapshots (e.g. yearly snapshots)
Pros: replay the change(need to verify that it works for everything), asynchrony? , audit, debugging, historic state
Cons: unfamiliar, can’t replay answers of external systems unless recorded, old event schema still has to work with new versions of the schema, IDs generated during replay are probably different than before
Extra:
- you can synchronously use event sourcing
- versioning or snapshots can make asynchrony easier
- doesn’t need to store application state/data in persistent storage, because have many data in event-sourcing to build the current state, and can use cache or in-memory instead
- an example, a trading system achieves high performance with only a single thread because it processes data in in-memory only (e.g. Redis to not lose any data before snapshots) and only stores data that snapshots every night in persistent storage
- Event Store should stay generic (git only knows txt, not the used programming language syntax)
- what events to store? input/internal/output, two events happen for a state change. One shows the intention (command), and the other shows all the different changes that were done. Events that show intention often hold specific knowledge, and the EventStore normally stays generic. It’s important to think about which of those events are important to persist. Probably both.
- what if the events are calculated wrong? just do data/state adjustment
Pattern 4: CQRS
Separate components for updating the system and reading from the system Different models of the data are pretty common (e.g. a reporting database), the important thing here is that the command model is never used for reading from outside
GOTO Conferences Youtube: The Many Meanings of Event-Driven Architecture • Martin Fowler • GOTO 2017
