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
  2. 10 Definition: Event An event is a fact. It’s an

    observation of something that has happened in the past.
  3. @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.
  4. @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:
  5. 15 Definition: Domain Event A domain event is a fact.

    It’s an observation of something interesting that has affected the domain.
  6. 23 Definition: Event Sourcing Instead of storing the current state

    of something, store a sequence of events that lead to the state.
  7. @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.
  8. 25 Definition: Event Streaming Publish a stream of events on

    a topic that other service can subscribe.
  9. @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.
  10. @lutzhuehnken You can do Event Sourcing Without: - Event Streaming

    - „listen to your own events“ from an external bus - Kafka
  11. @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.)
  12. @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.
  13. @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)
  14. @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.
  15. @lutzhuehnken Things that are not Events Commands - express an

    intention - can fail Queries - ask for information - return a result
  16. „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
  17. @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?
  18. @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)
  19. @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.
  20. 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