Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Events! Events Everywhere!

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

Lutz Hühnken

February 10, 2022
Tweet

More Decks by Lutz Hühnken

Other Decks in Programming

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