Events! Events Everywhere!

This is the deck I used for my talk about Event Driven Architecture (more specifically: Event Collaboration vs. Event Sourcing).

If you're interested in the topic, consider also reading the accompanying article: https://www.reactivesystems.eu/2022/06/09/event-collaboration-event-sourcing.html

I presented this on these three occasions:

w-jax Munich November 2021 - https://jax.de/software-architecture/softwarearchitektur-events-events-ueberall-events/

Microservices Meetup Hamburg February 2022 - https://www.meetup.com/de-DE/Microservices-Meetup-Hamburg/events/283402539/

code.talks Hamburg September 2022 - https://codetalks.de/program#talk-1131?event=7

2. 2 „The single biggest problem in communication is the illusion that it has taken place.“ George Bernard Shaw
3. Everybody Loves Events
4. @lutzhuehnken Great!
5. @lutzhuehnken Event Collaboration
6. @lutzhuehnken How it started
7. @lutzhuehnken How it’s going
8. @lutzhuehnken
9. @lutzhuehnken What’s the problem with this?
10. 10 Definition: Event An event is a fact. It’s an observation of something that has happened in the past.
11. @lutzhuehnken What’s the problem with this?
12. @lutzhuehnken But isn’t that also Event-driven? Not the fact that it’s asynchronous makes something an event. Not the fact that Kafka is being used makes something an event. Event is a specific kind of message, with specific semantics.
13. @lutzhuehnken With events, there’s no going back. If a receiver can’t process an event, it’s their problem. And this is beautiful! It’s what allows us to build this: instead of this:
14. @lutzhuehnken Not All Events Are Interesting UI Events (ButtonClicked,..) Log Events Outside World Events
15. 15 Definition: Domain Event A domain event is a fact. It’s an observation of something interesting that has affected the domain.
16. @lutzhuehnken How Domain Events Usually Come About
17. @lutzhuehnken Temporal Decoupling
18. @lutzhuehnken Event Sourcing?
19. @lutzhuehnken
20. @lutzhuehnken Event Sourcing Inside
21. @lutzhuehnken With CQRS
22. @lutzhuehnken With Event Streaming
23. 23 Definition: Event Sourcing Instead of storing the current state of something, store a sequence of events that lead to the state.
24. @lutzhuehnken Event Sourcing This happens inside your service! Typical technology: Any ol’ database (SQL, noSQL, eventstore, ..) (log-based message bus is also possible) It’s an approach to data persistence.
25. 25 Definition: Event Streaming Publish a stream of events on a topic that other service can subscribe.
26. @lutzhuehnken Event Streaming This is the basis for Event Collaboration between services! Typical technology: Log-based message bus (Kafka, Pulsar, Kinesis, EventHubs, PubSub,…) It’s an API.
27. @lutzhuehnken Listen to your own events?
28. @lutzhuehnken We talked about this..
29. @lutzhuehnken You can do Event Sourcing Without: - Event Streaming - „listen to your own events“ from an external bus - Kafka
30. @lutzhuehnken You can do Event Sourcing Without: - Event Streaming - Event Streaming for Collaboration (outside), Event Sourcing for Persistence (inside) - „listen to your own events“ from an external bus - Just one very special way of Event Sourcing with questionable benefits. - Kafka - There was Event Sourcing before Kafka. (But it’s great for event streaming.)
31. @lutzhuehnken And the other way around (Event Streaming and Event Collaboration without Event Sourcing)
32. @lutzhuehnken Fowler’s Types of Events Event Sourcing Events Notification Events Event-carried State Transfer
33. @lutzhuehnken Event Sourcing Events As covered - complete unrelated to Event Streaming / Event Collaboration. Persistence for „Data on the Inside“ Separation from collaboration should be clearer.
34. @lutzhuehnken Notification Events - Temporal decoupling is lost - Immutability may be lost Recommendation: - Only use references to immutable objects. - Use where payload is too big (e.g. generated documents)
35. @lutzhuehnken Event-carried State Transfer What we usually think of when we think of Domain Events. Can be further broken down, e.g. Fat Events.
36. Non-Events
37. @lutzhuehnken Things that are not Events Commands - express an intention - can fail Queries - ask for information - return a result
38. @lutzhuehnken Commands & Queries
39. @lutzhuehnken Events
40. @lutzhuehnken And this is beautiful! It’s what allows us to build this: instead of this:
41. „It is not the things that matter in early stages of design… …it is the things that happen.“ Russ Miles https://web.archive.org/web/20210126062147/http://www.russmiles.com/essais/going-events-first-for-microservices-with-event-storming-and-ddd 41
42. @lutzhuehnken Event-driven only on paper..
43. Summing it up.. 43
44. @lutzhuehnken Caveat Emptor If someone says Event Sourcing (or Events First), you must ask them to explain what they mean! Event sourcing within a service / bounded context? Or „data inside out“, with the message bus as permanent storage, i.e. using event streaming with infinite retention of events?
45. @lutzhuehnken Recommendation Be weary of „data inside out“ patterns where the transport between your services becomes the permanent storage and source of truth. Better: Clearly separate between data on the outside (think transport, not storage) and data on the inside (source of truth, persistence, governed by domain)
46. @lutzhuehnken Design Event-driven architecture doesn’t just happen. You have to design your processes in a way that you can leverage the advantages of event-driven architecture. Event Collaboration is the foundation of event-driven architecture.
47. PPT Master 16:9 / Edition 2018 „Going to microservices is like going from Newton’s physics to Einstein’s physics. Newton’s time marched forward uniformly with instant knowledge at a distance. Before microservices, distributed computing strove to make many systems look like one with RPC, 2PC etc.. In Einstein’s universe, everything is relative to one’s perspective.“ Pat Helland
48. Who can think of a good question?