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

Transcript

1. View Slide

2. 2
   „The single biggest problem in
   communication is the illusion that it has
   taken place.“
   
   
   George Bernard Shaw
   

   View Slide

3. Everybody Loves Events
   

   View Slide

4. @lutzhuehnken
   Great!
   

   View Slide

5. @lutzhuehnken
   Event Collaboration
   

   View Slide

6. @lutzhuehnken
   How it started
   

   View Slide

7. @lutzhuehnken
   How it’s going
   

   View Slide

8. @lutzhuehnken
   

   View Slide

9. @lutzhuehnken
   What’s the problem with this?
   

   View Slide

10. 10
    Definition: Event
    An event is a fact. It’s an observation of something that has
    happened in the past.
    
    
    

    View Slide

11. @lutzhuehnken
    What’s the problem with this?
    

    View Slide

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.
    
    
    

    View Slide

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:
    

    View Slide

14. @lutzhuehnken
    Not All Events Are Interesting
    UI Events (ButtonClicked,..)
    Log Events
    Outside World Events
    

    View Slide

15. 15
    Definition: Domain Event
    A domain event is a fact. It’s an observation of something
    interesting that has affected the domain.
    
    
    

    View Slide

16. @lutzhuehnken
    How Domain Events Usually Come About
    

    View Slide

17. @lutzhuehnken
    Temporal Decoupling
    

    View Slide

18. @lutzhuehnken
    Event Sourcing?
    

    View Slide

19. @lutzhuehnken
    

    View Slide

20. @lutzhuehnken
    Event Sourcing Inside
    

    View Slide

21. @lutzhuehnken
    With CQRS
    

    View Slide

22. @lutzhuehnken
    With Event Streaming
    

    View Slide

23. 23
    Definition: Event Sourcing
    Instead of storing the current state of something, store a sequence
    of events that lead to the state.
    
    
    

    View Slide

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.
    

    View Slide

25. 25
    Definition: Event Streaming
    Publish a stream of events on a topic that other service can
    subscribe.
    
    
    

    View Slide

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.
    
    
    

    View Slide

27. @lutzhuehnken
    Listen to your own events?
    

    View Slide

28. @lutzhuehnken
    We talked about this..
    

    View Slide

29. @lutzhuehnken
    You can do Event Sourcing Without:
    - Event Streaming
    
    
    - „listen to your own events“ from an external bus
    
    
    - Kafka
    
    
    

    View Slide

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.)
    
    
    

    View Slide

31. @lutzhuehnken
    And the other way around (Event Streaming and Event
    Collaboration without Event Sourcing)
    

    View Slide

32. @lutzhuehnken
    Fowler’s Types of Events
    Event Sourcing Events
    
    
    Notification Events
    
    
    Event-carried State Transfer
    
    
    

    View Slide

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.
    

    View Slide

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)
    

    View Slide

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.
    

    View Slide

36. Non-Events
    

    View Slide

37. @lutzhuehnken
    Things that are not Events
    Commands
    
    
    - express an intention
    
    
    - can fail
    
    
    Queries
    
    
    - ask for information
    
    
    - return a result
    

    View Slide

38. @lutzhuehnken
    Commands & Queries
    

    View Slide

39. @lutzhuehnken
    Events
    

    View Slide

40. @lutzhuehnken
    And this is beautiful! It’s what allows us to build this:
    instead of this:
    

    View Slide

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
    

    View Slide

42. @lutzhuehnken
    Event-driven only on paper..
    

    View Slide

43. Summing it up..
    43
    

    View Slide

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?
    
    
    

    View Slide

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)
    

    View Slide

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.
    
    
    

    View Slide

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
    

    View Slide

48. Who can think of a good question?
    

    View Slide