Jacqui Read: A Guide to Events in Software Architecture

I want to disambiguate the many uses of “event” in software: commands, streams, event-driven architecture, EventStorming, event sourcing and several kinds of event. Similar names do not necessarily mean the concepts are interchangeable.

An event represents something that has happened. The time of the occurrence matters, and the event records a fact rather than asking another component to perform an action. Existing software has used event objects for decades, including in graphical interfaces.

An event can carry information about a change, such as a changed preference. What it contains affects consumers: if they depend on the producer’s internal representation, changes to that representation can create coupling.

A command asks a known recipient to do something, with an expectation of action. An event publishes a fact that has already occurred; the publisher need not know who will react. Messages are the broader category that can include both.

For example, creating, starting and completing a work item can be expressed as commands and corresponding past-tense events. Distinguishing a request from a fact makes it easier to reason about what has actually happened.

Terminology around listeners and handlers varies. A listener waits for an event type and triggers callback code; some people call the callback the handler, while others use “handler” for the whole mechanism.

Event streaming handles continuous flows of data and can support near-real-time processing rather than waiting for a batch. Producers such as services or devices publish events; consumers subscribe to the information they need.

A message log stores entries with offsets. Consumers track their progress so they can resume after a failure. A consumer may replay records it already processed, so the processing design must account for idempotency; a new consumer may also choose a particular starting window.

A queue has different semantics in the example: one or more competing consumers take messages, and an acknowledged message is no longer available on that queue. If processing is not acknowledged, it can become available again for another consumer.

In a command-driven network, services may know and call one another directly. An event-driven architecture can instead use a broker for publication and subscription, reducing some direct dependencies. The broker itself still needs to be designed for the required reliability and throughput.

That indirection has a cost: a diagram showing only services and a broker may hide who ultimately consumes data. In a distributed system, following downstream dependencies and predicting the effects of a change can become difficult.

EventStorming brings business and technical participants together to map events, actors, systems, opportunities and trouble spots. The point is to uncover knowledge held by different people and understand what happens next, rather than assume that all of it is documented.

Pivotal events can reveal transitions between bounded contexts. Teams may disagree over terminology at those boundaries because the same information is understood through different domain models; identifying the boundary helps make translation explicit.

A big-picture EventStorming session is broad discovery with many participants. Process modeling narrows the group to design or redesign a workflow, while software-design sessions focus further on technical and user-experience decisions.

Event sourcing stores changes as events rather than only the latest state. Replaying those changes can reconstruct a past state, much as a version history helps inspect earlier versions. A conventional state store may need separate logs or backups to recover the same history.

She describes using streams for entities or aggregates and splitting long-running streams at useful business boundaries. The appropriate boundary depends on write volume and domain needs; a cache or projection can make current-state reads faster.

An event store can be a specialized database or a general database with supporting software. Events represent past facts and are generally not edited in place. The speaker mentions encryption and deleting keys as one possible privacy technique; whether that meets a particular legal obligation depends on the implementation and applicable requirements.

A tombstone generally marks that data is no longer present, but its exact meaning depends on the system. She contrasts marking a stream for deletion, filling a sequence gap and signaling completion in a retry pattern; the same word is used for different purposes.

In the retry example, an event that cannot yet be processed is redirected, and subsequent related events are also held for retry so they do not overtake it. A completion marker helps the main flow know when the redirected work has finished.

Domain events describe meaningful occurrences within a domain or bounded context; integration events communicate across boundaries. The speaker urges teams to design events as deliberately as APIs and consider the models shared between producers and consumers.

Event granularity involves a tradeoff. A small notification may require a consumer to call the producer for more data, adding coupling and latency; an oversized event may distribute irrelevant information and create other dependencies.

Her advice is to make events as small as possible but as large as necessary for consumers to act without immediately calling the producer back. The right size depends on the workflow and its consumers, not a universal payload template.

The talk closes by reviewing the terminology and pointing to further learning resources. Understanding the distinctions helps teams choose the appropriate pattern rather than assuming all event-related techniques solve the same problem.