Preface

Whenever I am learning more about topics, I like to read books, blog pots & watch videos whilst taking notes. I update these notes as I digest new material and refer to them whenever I need to. Below is everything I have learnt so far on Event Driven Architecture. This will be updated over time.

Wherever I have put MJB: xxx, this is a comment or question I am asking myself as I read/watch the source material, and it is not a direct note.

I hope others find this useful.

Notes From What do you mean by “Event-Driven”? - Martin Fowler

https://martinfowler.com/articles/201701-event-driven.html

Event Notification

• System sends an event to let others know about changes in its domains. Doesn’t care too much about responses and if it does it might hear about them indirectly.
• A push notification is a great example of an event notification.
• There is low coupling between systems with this event notification.
• Can be really hard to track the logical flow of the system as you do not know who will receive it and what will happen next. Often the only way to find out is to watch the live system.

Event-Carried State Transfer

• This pattern is used to update clients of a system in such a way that they don’t need to contact the source system to do further work.
• Example: A customer management system might fire off events whenever a customer changes their details (such as an address) with events that contain details of the data that changed. A recipient can then update it’s own copy of customer data with the changes, so that it never needs to talk to the main customer system in order to do its work in the future.
• This means shipping a lot of information around the system - less of an issue as storage gets cheaper.
• we gain is greater resilience, since the recipient systems can function if the customer system is becomes unavailable.
• We reduce latency, as there’s no remote call required to access customer information.
• We don’t have to worry about load on the customer system to satisfy queries from all the consumer systems.
• More complexity on the receiver, as they have to manage state themselves.
• MJB: Need to be really careful with this pattern in regards to PII data, PCI data. How will this work? Would you end up with a hybrid Event Notification/ECST system?

Event Sourcing

• Whenever we make a state change in the system, we store a record of that change.
• The record log should be immutable.
• We should therefore be able to rebuild the state of the system (or a subsection of it) at any time using the events.
• The event store is the source of truth.
• Best example is source control - git.
• People often assume that event sourced system need to be asynchronous, that isn’t true.
• When working with an event log, it is often useful to build snapshots of the working copy so that you don’t have to process all the events from scratch every time you need a working copy.
• The event log provides a strong audit capability (accounting transactions are an event source for account balances).
• We can explore alternative histories by injecting hypothetical events when replaying.

CQRS

• Command Query Responsibility Segregation is the notion of having separate data structures for reading and writing information.
• This isn’t strictly anything to do with events, but it often gets combined with the patterns above.
• The justification for CQRS is that in complex domains, a single model to handle both reads and writes gets too complicated, and we can simplify by separating the models.

Notes From A decade of event sourcing - a retrospective by Greg Young

https://www.youtube.com/watch?v=LDW0QWie21s

General

• CQRS was coined by Gregg Young ~2007
• CQRS is a stepping stone from DDD to append only events and event sourcing. It’s not so relevant today. It needs to be considered in its historical context.
• Event sourcing is an append only log of facts - things that have happened.
• Cloud computing and immutable infrastructure also helped push forward the idea of event sourcing.

Good

• Event sourcing was commonly used in high transactional domains (banking, lottery, finance).
• Event sourcing changed the perspective of domain experts when they used an event sourced system.
• Forces a focus on timing. What happens if X happens before Y? Has helped system modellers really understand the domain.
• “The system isn’t the book of record, the warehouse is. People don’t check out things properly when they are stealing them"
• Event storming is a great concept to really understand your domain. It can also help you find service boundaries.
• Recommended by Gregg as a worthwhile exercise that will become more and more popular.

The Bad

• Event Sourcing should not be a top level architecture. An example would be in a CRUD based system I might enter some info, press save. I then realise I got it wrong and need to correct it. In an ES system I need an event for this correction. Can get confusing super quickly. Recommended for only subsections of the system.
• People often take the “rules” too literally and it Makes really complex systems. “You must always separate the read and write side”
• Inputs and outputs should not be 1 to 1. This is often a big mistake people make when building these systems. A “place Order command” doesn’t need to only yield a “order placed” event
• Commands don’t need to be one way and do not need to return void. If someone wants to withdraw money from an atm, I record the fact they tried to do this, but it doesn’t mean the system cannot say “no you cannot do that”.
• You need to accept your system is not the book of record. If I steal all the money from the atm, what will the system say? The atm is the real book of record. Accepting this fact changes the way you think about things.
• Don’t write a CQRS framework. It’s a bad idea. They all get abandoned.

The Future

• More functional Programming with Event Sourcing.
• More process managers - like AKA.
• More Client side event sourcing “user is offline” “user is now online” <— synchronisation.
• N-Temporal event sourcing - there may be multiple timelines we are interested in.

Changelog:

• 08/05/2020 First published.