$30 off During Our Annual Pro Sale. View Details »

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

More Decks by Lutz Hühnken

Other Decks in Programming


  1. None
  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?