Notes from watching The Many Meanings of Event-Driven Architecture - Martin Fowler -GOTO 2017
This post also covers it: https://martinfowler.com/articles/201701-event-driven.html
If System A needs to communicate with System B, i.e. a customer management system needs to tell a quoting system to trigger a requote, then if it's via API A needs to know B's API, etc.
However, if system A dispatches an event, and system B is listening to those events, then A doesn't know about B. The dependency is reversed: System B now knows about the events A emits instead o A knowing about B's APIs.
This is how textboxes work -> They trigger events and the code does stuff. The textbox doesn't know about the rest of the app.
These can be called events or commands. What's the difference? The difference is just about language, communication and ultimately, intention. Events communicate a change, without necessarily expecting a response. Commands expect a result. Behind the scenes, they're messages in queues, but naming is important.
Adding a new piece of functionality can mean simply tapping into an event stream -> You don't need to have a team call your API, hence remove the dependency from another team. What's the but? There is no longer a defined list of things that happen upon a certain action. Event consumers are decoupled. There is no statement of overall behaviour. GUIs behave like this. This is the dark side of event architectures.
Now, depending on what you're sending in the event, if it's just a "something's changed" message, consuming services might then have to get in touch with the producing service to get the data that actually changed. This means additional traffic. This can be reduced, even eliminated, by pushing more information to the event, up to the logical place of putting ALL relevant information in the event.
Upstream services send all relevant data in the event, and downstream services keep copy of everything they need to reuse. The benefit is, we no need to rely on upstream service databases, the downside is, I need to copy the data I need. This also decouples in terms of availability. If system B has all the data it needs, it can go along without caring if system A is down. What's the gotcha? Eventual consistency.
In a standard system, to change a piece of data, say customer address, this means deleting the old address and adding the new one. In event sourcing applications, we create an event, and then delete the old address and add the new one based on the information in the event. But the event is saved. What this means is, we have the application state, and a log of all the events that ever happened and eventually took us to that application state. In other words, by running all the events, we should be able to get the final application state. At any point, we should be able to blow up the app state, and rebuild it from scratch thanks to the log. A good example is Git: it's an event sourced system. An event sourced system is providing to the user what Git provides to developers. Another example is an account ledger.
Now, the story is always a mix of snapshots and logs: you can always start from an original snapshot and logs from there on.
PROS:
- Great audit system.
- Good to debug stuff. Just like redux's timetravel.
- Allows for alternative branching.
- Allows for an in-memory app state.
CONS:
- Unfamiliar system
- Doesn't play well with external systems
- Doesn't play well with identifiers, adds complexity
- Async processing adds complexity -> not that it's necessary. You can do sync ES.
- Versioning can get messy. It can be avoided by not having any business logic between the event and storing the event
CQRS's about separating the components that read data and the ones that run updates. They're different pieces of software. The main advantage of this is simplifying different parts of the domain.
Talk: https://www.youtube.com/watch?v=jrbWIS7BH70
We think separating concerns is about separating concerns in boxes, but this all ends up in a big ball of mud.
Why microservices? What's the big promise? It's all about agility: making changes without changing the whole system, and scalability (team scalability). It's not about computing scalability but team scalability.
However microservices comes with extra complexity. Hence all the Netflix OSS tools.
How do we decide what's in one service and what's in another? In practice, most folks do noun-driven-design. Noun? -> Service. InventoryService, ProductService, etc. However that's not very different to having a lot of small balls of mud. If we find ourselves deploying multiple services at the same time everytime... we're there.
What we really have to do is increase the modularity. But this can be done in a monolith too. Once we really understand the modules, the independent domains, then it makes sense to start breaking down the independent deployment units. If only it were that simple :)
There are anti-modularity evil forces:
- Deadlines -> shortcuts
- Tech-debt
However, that requires discipline. If you can't build a monolith... forget about microservices. There's a journey to it. Now, to forgoe this journey, location transparency is the means: a component should neither be aware of nor make any assumptions about the location of components it interacts with. This is all about good API design.
Events to the rescue. Events is about dependency inversion.
Stopped watching at this point. I felt like it wasn't worth my time.