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. 2
    „The single biggest problem in
    communication is the illusion that it has
    taken place.“


    George Bernard Shaw

    View full-size slide

  2. Everybody Loves Events

    View full-size slide

  3. @lutzhuehnken
    Great!

    View full-size slide

  4. @lutzhuehnken
    Event Collaboration

    View full-size slide

  5. @lutzhuehnken
    How it started

    View full-size slide

  6. @lutzhuehnken
    How it’s going

    View full-size slide

  7. @lutzhuehnken

    View full-size slide

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

    View full-size slide

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


    View full-size slide

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

    View full-size slide

  11. @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 full-size slide

  12. @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 full-size slide

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

    View full-size slide

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


    View full-size slide

  15. @lutzhuehnken
    How Domain Events Usually Come About

    View full-size slide

  16. @lutzhuehnken
    Temporal Decoupling

    View full-size slide

  17. @lutzhuehnken
    Event Sourcing?

    View full-size slide

  18. @lutzhuehnken

    View full-size slide

  19. @lutzhuehnken
    Event Sourcing Inside

    View full-size slide

  20. @lutzhuehnken
    With CQRS

    View full-size slide

  21. @lutzhuehnken
    With Event Streaming

    View full-size slide

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


    View full-size slide

  23. @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 full-size slide

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


    View full-size slide

  25. @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 full-size slide

  26. @lutzhuehnken
    Listen to your own events?

    View full-size slide

  27. @lutzhuehnken
    We talked about this..

    View full-size slide

  28. @lutzhuehnken
    You can do Event Sourcing Without:
    - Event Streaming


    - „listen to your own events“ from an external bus


    - Kafka


    View full-size slide

  29. @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 full-size slide

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

    View full-size slide

  31. @lutzhuehnken
    Fowler’s Types of Events
    Event Sourcing Events


    Notification Events


    Event-carried State Transfer


    View full-size slide

  32. @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 full-size slide

  33. @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 full-size slide

  34. @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 full-size slide

  35. @lutzhuehnken
    Things that are not Events
    Commands


    - express an intention


    - can fail


    Queries


    - ask for information


    - return a result

    View full-size slide

  36. @lutzhuehnken
    Commands & Queries

    View full-size slide

  37. @lutzhuehnken
    Events

    View full-size slide

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

    View full-size slide

  39. „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 full-size slide

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

    View full-size slide

  41. Summing it up..
    43

    View full-size slide

  42. @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 full-size slide

  43. @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 full-size slide

  44. @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 full-size slide

  45. 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 full-size slide

  46. Who can think of a good question?

    View full-size slide