Every Event, Everywhere, All at Once: Untangling Event-Driven Architecture Terminology

Jacqui Read began her talk by acknowledging the widespread confusion and anxiety that the sheer volume of event-related terminology can cause among developers and architects. She noted that with so many different types of events and related concepts, it's easy to feel disoriented.

The primary goal of her presentation, Read explained, was to provide clarity and disambiguation, helping attendees to better understand the nuances and applications of various event types within event-driven architectures.

Read distinguished between the general understanding of an event and its specific technical usage in computing, noting that general definitions often relate to outcomes or results.

She clarified that while calendar events can refer to occurrences in the past, present, or future, technical events in computing are specifically focused on immutable occurrences that have already happened.

According to Read, the closest umbrella definition for a computer event is "something that has happened," emphasizing its nature as a record of a past occurrence with an unchangeable outcome.

Events, as a concept in computing, are not new and have been integral to software development for decades, Jacqui Read explained.

She highlighted the introduction of specific event types, such as `PreferenceChangeEvent` and `PropertyChangeEvent`, in JDK 1.1, which was released in 1997.

These early patterns of event usage were primarily focused on user interface (UI) interactions, laying the groundwork for more complex event-driven systems seen today.

Jacqui Read pointed out a common pitfall in modern event design: modeling multiple state changes, such as an item being added, removed, or changed, within a single event. This practice, while seemingly efficient, can lead to significant problems.

One major issue is that consumers of such an event may not require all the encapsulated information, leading to unnecessary processing overhead. This means that services interested in only one specific state change must still process an event containing data for other irrelevant changes.

Events often serve as wrappers for identifiers and values, and when too much information is bundled, it can inadvertently create tight coupling between the event producer and its consumers, making systems less flexible and harder to maintain.

Jacqui Read explained that in a message log, each message is appended with a unique offset, typically starting from zero, which serves as its position identifier within the log.

Consumers process these messages sequentially and track their progress by periodically recording the last offset they have successfully processed. This recording can happen after a certain number of messages or a specific time interval.

This mechanism is vital for ensuring system resilience; if a consumer crashes or restarts, it can use its last recorded offset to resume processing from the correct point, preventing data loss or reprocessing of already handled messages.

Jacqui Read highlighted a critical challenge in message processing: consumers must be prepared to handle situations where they restart and need to determine which messages have already been processed.

She emphasized that idempotency is crucial here. An idempotent operation is one that can be applied multiple times without changing the result beyond the initial application. This property prevents adverse side effects if a message is processed more than once, which can occur during recovery from a failure when a consumer might re-read messages it had already handled.

Jacqui Read clarified a fundamental difference between message queues and message logs: in a message queue, an item is removed from the queue as soon as the consuming application confirms its successful processing.

If a consumer fails to confirm processing, the message becomes available again on the queue for another consumer to pick up, ensuring that messages are eventually processed.

This behavior contrasts sharply with event streaming systems, where messages persist in a log regardless of their consumption status, allowing multiple consumers to read the same message or for historical replay.

Jacqui Read contrasted command-driven architectures with event-driven ones, noting that command-driven systems often exhibit high coupling. In such systems, services typically communicate directly, sending commands to each other, meaning each service has explicit knowledge of others.

In an event-driven architecture, services achieve decoupling by communicating through a central broker. Services publish events to the broker, and other services subscribe to these events without needing direct knowledge of the publishers.

While this decouples services, Read pointed out that the architectural diagrams for event-driven systems can obscure direct service-to-service communication, shifting the visibility and understanding of data flow to the central broker.

Jacqui Read used the analogy of a "wall of ivy" to describe the complexity of distributed systems. She explained that just as it's hard to trace individual stems in a dense ivy wall, it becomes increasingly difficult to determine where data originates and where it flows in a distributed environment, especially as the system grows.

This difficulty extends to knowing which services are consuming specific data and how that data is being utilized further downstream in the system.

Consequently, making changes in a distributed system is riskier than in a monolithic application, as unforeseen repercussions can easily arise due to the obscured data flow and interdependencies.

Jacqui Read detailed the core components of event storming, a collaborative workshop format for modeling complex business domains. She explained that orange sticky notes are universally used to represent events, which are crucial occurrences within the domain.

Opportunities, marked by a specific type of marker, are identified when participants see potential for improvement, enhancement, or the addition of new features within the modeled process. Hotspots, on the other hand, highlight problems, disagreements, or areas of contention that require further discussion and resolution.

Actors, typically represented by yellow notes, are the individuals or systems that initiate actions or interact with the events, while votes indicate areas that the team collectively decides to prioritize or focus on for further exploration or development. This standardized visual language facilitates understanding and collaboration across diverse teams.

Jacqui Read discussed the options for storing events in an event-sourcing architecture, explaining that while a generic data store can be used, it requires writing significant custom code to manage event-specific functionalities.

To mitigate this, she recommended using wrapper tools like Message DB or Marten, which provide the necessary abstraction and functionality to enable generic data stores to work effectively with event sourcing.

Alternatively, dedicated event stores such as EventStoreDB offer specialized features optimized for event-sourcing patterns, inherently supporting the 'write-once, read-many' paradigm essential for immutable event logs.

Jacqui Read addressed the challenge of GDPR compliance in event stores, particularly the 'right to be forgotten,' given that event logs are inherently immutable and cannot be directly edited to delete personal data.

She proposed encryption as the most straightforward solution. By encrypting GDPR-sensitive data within the event store and holding a separate encryption key, compliance can be achieved.

When a user requests their data to be deleted, the encryption key is simply deleted, rendering the stored encrypted data permanently unrecoverable and effectively removed from access.

Jacqui Read introduced the concept of tombstone events, which at a high level, signify that certain data is no longer present or considered active, without physically deleting the historical record.

In systems like EventStoreDB, tombstone events are used to mark an entire stream for deletion, indicating that its contents should no longer be actively processed or retrieved, while maintaining the integrity of the event log.

For Marten, tombstone events play a role in maintaining sequence integrity, particularly when failures occur, ensuring that the system can accurately track the state of data even when certain records are logically marked as removed.

Jacqui Read explained a common Kafka retry pattern designed to handle event processing failures while maintaining message order. When an event enters the main application and cannot be processed successfully, it is recorded in a database and then placed onto a dedicated retry topic.

Subsequent events continue to be queued, ensuring that the overall order of events is preserved even if a preceding event is temporarily stalled. The system then attempts to retry the failed event from the retry topic.

Upon successful processing of the retried event, a tombstone event is generated. This tombstone event serves to clear the corresponding record from the retry queue, signifying that the event has finally been handled and its lifecycle is complete.

Jacqui Read distinguished between domain events and integration events, starting with domain events, which she attributed to Eric Evans' seminal 'orange book' on Domain-Driven Design.

Domain events are defined as representations of something that happened in the past tense within a specific domain boundary, capturing occurrences that domain experts care about.

Integration events, in contrast, are specifically used for communication between different subdomains or bounded contexts, facilitating interaction across distinct parts of a larger system.

Jacqui Read suggested that thinking about events through the lens of API design, specifically public versus private APIs, can provide a clearer classification.

She argued that rather than distinct 'domain' and 'integration' APIs, it's more practical to categorize them as public and private.

This perspective frames all events, regardless of their scope, fundamentally as domain events that can then be exposed either publicly or kept private depending on their intended audience and usage.

Jacqui Read elaborated on defining boundaries for different event types, specifically distinguishing between private and public events. She explained that private events are primarily for internal communication within a specific service or team, used for the ongoing work and interactions within that bounded context.

Public events, conversely, are those intended for consumption by external systems or other distinct bounded contexts. These events require careful versioning and a more formal contract, similar to public APIs, due to their broader impact and potential for breaking changes.

She also touched upon the concept of shared models and pivotal domain events, which represent critical occurrences that cut across multiple domains and are often exposed as public events.

Jacqui Read warned against what she termed "clickbait events" – events that contain minimal information and essentially act as mere notifications. While seemingly lightweight, these events often force consumers to make subsequent back-channel requests to the producer to retrieve necessary details.

This pattern introduces significant latency due to repeated network calls and creates tight coupling, as consumers become dependent on the producer for complete data, undermining the benefits of event-driven decoupling.

Furthermore, without proper event sourcing, relying solely on clickbait events can lead to data consistency issues, as the consumer's view of the data might be stale or incomplete if they have to query the current state from the producer rather than reconstructing it from a stream of complete events.