Every Event, Everywhere, All at Once • Jacqui Read • GOTO 2025

Overview

• Speaker: Jacqui Read
• Channel: GOTO Conferences
• Main topic: Disambiguating event-driven architecture terminology, patterns, and concepts
• Purpose: To clear up confusion around event-driven terminology and provide software architects and developers with clear patterns and definitions for designing event-driven systems. Jacqui Read presents a comprehensive guide to understanding and disambiguating event-driven architecture terminology and patterns. The talk walks through what an event is, differentiates events from commands and messages, explores event listeners, handlers, event streaming, message logs, message queues, event sourcing, tombstone events, and event-driven architecture versus command-driven architecture. She concludes with guidelines on event granularity and designing events like APIs.

Topic Map

What is an Event?

• Explanation: Explores dictionary and computing definitions of events, emphasizing that a computing event represents something that has already happened with a definitive outcome.
• Key claims:
  • A computing event is something that has already happened.
  • Events are immutable facts that cannot be changed once published.
• Examples:
  • Java EventObject from JDK 1.1
  • PreferenceChangeEvent and PropertyChangeEvent
• Terminology:
  • Event
  • EventObject
  • Computing Event
• Why it matters: Understanding the fundamental definition of an event prevents confusion with commands or calendar events.

Event vs. Command

• Explanation: Compares commands and events as two types of messages, highlighting that commands express intention and expect something to happen, whereas events represent published facts with no expectation of a response.
• Key claims:
  • Commands represent intent and are sent to a specific target expecting an action.
  • Events are published facts that state what happened without expecting anything in return.
• Examples:
  • Batman intent vs. cat-on-head result (fact)
• Terminology:
  • Command
  • Message
  • Intent
  • Result
  • Fact
• Why it matters: Distinguishing between intent and fact is crucial for designing loose coupling in distributed systems.

Event Listeners, Handlers, Streaming, Logs, and Queues

• Explanation: Clarifies the components of message delivery, contrasting event listeners and handlers, message logs with offsets, and message queues with competing consumers.
• Key claims:
  • Event listeners trigger asynchronous callback code when an event occurs.
  • Message logs maintain ordered offsets where multiple consumers can read independently.
  • Message queues use competing consumers where processed items are removed from the queue.
• Examples:
  • Star Trek captains log and intercepted/docked messages
• Terminology:
  • Event Listener
  • Event Handler
  • Event Streaming
  • Message Log
  • Message Queue
  • Offset
  • Idempotency
• Why it matters: Choosing the right messaging infrastructure depends on whether you need pub-sub streaming or point-to-point queuing.

Event-Driven Architecture (EDA) vs. Command-Driven

• Explanation: Compares command-driven architectures (high coupling, direct service calls) with event-driven architectures (low coupling via brokers and pub-sub).
• Key claims:
  • Command-driven architectures lead to complex networks of high coupling between services.
  • Event-driven architectures decouple producers and consumers through brokers using publish-subscribe.
• Examples:
  • Service-to-service webs vs. broker-mediated event meshes
• Terminology:
  • Event-Driven Architecture
  • EDA
  • Broker
  • Publish-Subscribe
  • Coupling
• Why it matters: EDA reduces system coupling and improves scalability in distributed microservice environments.

EventStorming and Bounded Contexts

• Explanation: Explores EventStorming as a collaborative modeling method to break down silos and identify pivotal events and bounded contexts.
• Key claims:
  • EventStorming extracts knowledge from peoples' heads to break down organizational and technical silos.
  • Pivotal events mark the boundaries where information shifts across contexts.
• Examples:
  • Ship docked, resupply started, resupply finished
• Terminology:
  • EventStorming
  • Pivotal Event
  • Bounded Context
  • Hotspot
  • Opportunity
• Why it matters: EventStorming helps teams align business language and discover domain models collaboratively.

Event Sourcing and Tombstones

• Explanation: Defines event sourcing as storing state changes as a sequence of events rather than current state, and explains tombstone events for marking data deletion or non-existence.
• Key claims:
  • Event sourcing stores history of state changes, allowing state reconstruction at any point in time.
  • Tombstone events indicate that data is no longer present or valid in a stream.
• Examples:
  • USS Enterprise state updates vs. event logs
  • Kafka tombstone error handling pattern 4
• Terminology:
  • Event Sourcing
  • Stateful Entity
  • Sourced Entity
  • Tombstone Event
  • Versioning
• Why it matters: Event sourcing provides robust auditing, debugging, and temporal querying capabilities.

Event Granularity and Domain Events

• Explanation: Discusses the continuum of event payload sizes from notifications to event-carried state transfer, and argues that events should be designed like APIs.
• Key claims:
  • Event granularity ranges from minimal notifications to full event-carried state transfer.
  • Events should be designed as small as possible and as large as necessary.
  • Domain events are integration events that domain experts care about and should be designed like public APIs.
• Examples:
  • Clickbait notifications vs. kitchen-sink events
• Terminology:
  • Event Granularity
  • Notification
  • Event-Carried State Transfer
  • Domain Event
  • Integration Event
• Why it matters: Proper event granularity balances network overhead with consumer coupling risks.

Key Points

Events represent past facts, not future intentions

• Explanation: Confusing commands (intent) with events (facts) leads to architectural tightly-coupled anti-patterns.
• Evidence: Comparison of command request-response vs event publish-subscribe models.
• Practical implication: Always name events in the past tense (e.g., PreferenceChanged).

Event sourcing mirrors version control systems like Git

• Explanation: Instead of storing current state in a table row, event sourcing stores every state change event in order.
• Evidence: Comparison of stateful database tables versus event stream history logs.
• Practical implication: Enables complete audit trails and time-travel debugging.

Events need careful granularity design

• Explanation: Too little data requires costly callbacks; too much data increases coupling and privacy risks.
• Evidence: The event granularity continuum from notifications to event-carried state transfer.
• Practical implication: Design events to be as small as possible and as large as necessary.

Frameworks, Models & Processes

Big-Picture EventStorming Legend

• How it works: Collaborative workshop using sticky notes of different colors to map out domain events and business processes.
• Components:
  • Orange sticky notes (Events)
  • Yellow sticky notes (Actors)
  • Green sticky notes (Opportunities)
  • Pink sticky notes (Hotspots / Systems)
  • Yellow tape (Bounded Context boundaries)
• When to use: When discovering domain boundaries and designing new microservice architectures.

Event Granularity Continuum

• How it works: Evaluates event payload size and information richness from simple notifications to full state transfers.
• Components:
  • Notification (Less data, requires callback)
  • Status / State
  • Event-Carried State Transfer (More data, self-contained context)
• When to use: When deciding what data payload to include in an event message.

Examples & Case Studies

Java EventObject and PreferenceChangeEvent introduced in JDK 1.1 in 1997

• Illustrates: Early computing usage of event-driven patterns for UI preference updates.
• Lesson: Event-driven programming has deep roots in standard libraries long before modern microservices.

Star Trek Captains Logs in message queues

• Illustrates: How message logs with offsets allow multiple consumers to track state at their own pace.
• Lesson: Message logs retain history allowing consumers to replay or recover from failures easily.

Actionable Takeaways

• Immediate:
  • Name events in the past tense to reflect immutable facts.
  • Avoid chatty back-and-forth callbacks by choosing appropriate event payload sizes.
• Strategic:
  • Treat events like public APIs with clear versioning and domain boundaries.
  • Use EventStorming to break down organizational silos and discover bounded contexts.
• Questions to investigate:
  • How do our current event schemas handle versioning and backward compatibility?
  • Are we misusing commands as events in our microservice communication?

Claims Worth Verifying

• Java EventObject and AWT event classes were introduced in JDK 1.1 in 1997. (historical fact)
• Event sourcing immutability stores all state mutations as event streams. (architectural pattern)

Notable Quotes

"Every Event, Everywhere, All at Once" (at 0:13) "A computing event: something that has happened." (at 5:31) "Events should be designed like APIs." (at 52:15)

Compressed Summary

• events represent immutable facts that have happened in the past
• commands express intent while events publish facts
• event streaming and message logs provide decoupled pub-sub messaging
• event sourcing stores state history as a sequence of change events
• event granularity requires balancing notification size with consumer coupling
• Keywords: events, architecture, messaging, streaming, sourcing
• Core insight: Properly disambiguating event-driven terminology and designing events like APIs is essential for building loosely coupled, maintainable distributed systems.