Key terms for events, messaging, schemas, delivery guarantees, and coordination models.
This appendix is a practical vocabulary guide for the rest of the book. Event-driven architecture becomes much easier to reason about when similar terms stop blurring together. The goal here is not to provide one perfect universal dictionary. The goal is to keep the most important terms distinct enough that design reviews, incidents, and pattern choices stay precise.
Use the glossary in two ways:
flowchart TD
A["Event meaning"] --> B["Transport shape"]
B --> C["Consumer behavior"]
C --> D["Workflow and recovery"]
D --> E["Governance and operations"]
A --> F["Time and stream state"]
What to notice:
Event: A record that something happened. In strong event-driven design, an event usually describes a business fact rather than asking another system to perform work.
Domain event: An event with stable business meaning inside a domain, such as order.placed or payment.authorized. Domain events are stronger than vague technical change signals because consumers can reason about them in business terms.
Notification event: A lightweight event that mainly tells consumers something changed, often with only an identifier or small context payload. Notifications are useful, but they often create callback traffic if consumers need more detail immediately.
Event-carried state transfer: A pattern where the event includes enough business state for consumers to act locally without immediately fetching details from the producer. This improves consumer autonomy but creates a heavier public contract.
Command: A request asking another component to do something. A command is not the same as an event. An event says what happened. A command says what should happen next.
Task: A unit of work to be processed, often used in queue-based systems. Tasks and events overlap sometimes in implementation, but the design intent differs. Tasks are usually work distribution artifacts. Events are usually fact distribution artifacts.
Schema: The structure and meaning of an event contract. Schema is not only field shape. In practice it also includes field meaning, optionality, and compatibility expectations.
Compatibility: The extent to which different versions of a producer, consumer, or retained event history can still work together safely. Compatibility is a contract-evolution property, not only a parser property.
Producer: The component or service that emits an event. In event-driven systems, the producer owns both the timing of publication and the meaning of the event contract it publishes.
Consumer: The component or service that receives and reacts to an event. Consumers may update state, build projections, trigger workflows, send external effects, or simply filter and forward data.
Topic: A named channel often associated with publish/subscribe fan-out. Several consumers may subscribe independently to the same topic and each receive the event.
Queue: A named channel often used for work distribution, where messages are typically consumed by one worker from a competing group rather than by every subscriber independently.
Stream: A durable ordered log of events, often retained long enough to support replay, reprocessing, or analytics. Streams are especially important when event history itself matters.
Partition: A subset of a topic or stream that preserves local order. Partitioning improves scale, but it also defines which events stay ordered together.
Offset: A position inside a stream or partition. Offsets help consumers track progress through retained event history.
Broker: The platform component that stores, routes, and delivers events or messages between producers and consumers. A broker is transport infrastructure, not the architecture by itself.
Event time: The time the business fact actually occurred. This is often the right clock for analytics or business reporting.
Processing time: The time a consumer handled the event. This is often useful for operations, lag monitoring, and throughput analysis.
Ordering: The sequence in which events are expected to be applied. In practical systems, ordering is usually local to a key or partition rather than global across the entire platform.
Idempotency: The property that repeated handling does not create harmful duplicate business effect. Idempotency matters because retries, replay, and redelivery are normal in distributed systems.
Replay: Re-reading retained historical events. Replay is useful for rebuilding projections, correcting bugs, or backfilling new models, but it is dangerous when side effects are not replay-safe.
Backfill: Reprocessing a historical event range to generate missing derived output, such as a new dashboard view or corrected analytical model.
Projection: A read model derived from events for a specific query or operational purpose. Projections are usually reconstructable and are not normally the original source of truth.
Materialized view: A stored projection optimized for query use. In event-driven systems, a materialized view often means a persistent read-side table, index, or document updated from event flow.
At-most-once: A delivery model that favors avoiding duplicates even if some messages may be lost.
At-least-once: A delivery model that favors eventual handling even if duplicates may occur.
Effectively-once: A practical business outcome where duplicates may occur in transport, but the application prevents harmful duplicate business effect.
Dead-letter queue (DLQ): A holding area for messages or events that repeatedly fail processing and should be isolated from the normal path. A DLQ is useful only if diagnosis and replay discipline exist around it.
Poison message: An event that repeatedly causes failure for a given consumer path. A poison message may be malformed, semantically invalid, or incompatible with current logic.
Backpressure: A condition where downstream consumers or dependencies cannot keep up with incoming event volume. Backpressure is a flow-control problem, not merely a metrics problem.
Quarantine: A controlled holding path for suspicious or bad events that need inspection or repair before safe replay.
Choreography: A workflow style where services react to each other’s events and the process emerges from those reactions. Choreography becomes risky when the end-to-end process is no longer visible.
Orchestration: A workflow style where one coordinator explicitly tracks the process and decides which step should happen next. Orchestration improves visibility but can become overly central if it grows without discipline.
Saga: A long-running business process composed of local transactions plus explicit recovery behavior. A saga may be choreographed or orchestrated. The key idea is that failure recovery is part of the process model.
Compensation: Business correction logic run after earlier steps succeeded and a later step failed. Compensation is not the same as database rollback because many business effects are only partially reversible.
Correlation ID: An identifier that ties related messages, events, or workflow steps into one logical business path. It is useful for tracing and diagnosis.
Trace ID: An identifier representing one broader causal path across services and consumers. In asynchronous systems, trace graphs often branch rather than staying linear.
Event catalog: A discoverable record of event subjects, owners, purpose, lifecycle, and contracts. A catalog makes the event estate governable rather than informal.
Ownership: The responsibility for event meaning, schema evolution, lifecycle, and incident questions. Shared infrastructure without clear ownership usually becomes hard to change safely.
Retention: How long events remain stored and replayable. Retention is part of platform behavior, cost, and privacy design.
Tenant isolation: The controls that prevent one tenant’s event data from leaking into another tenant’s processing path or derived outputs. Tenant labels alone are not the same as tenant isolation.
Workload identity: A service or machine identity used by producers and consumers to authenticate to the platform. Strong workload identity is usually safer than shared static credentials.
Event vs command: An event describes a fact that already happened. A command asks for action. If one component is telling another exactly what to do next, you are probably in command territory.
Notification vs event-carried state transfer: A notification says “something changed.” Event-carried state transfer says “something changed, and here is enough state for you to act locally.” The second usually reduces callback traffic but increases contract weight.
Queue vs topic: A queue usually distributes work across workers. A topic usually broadcasts a fact to many independent consumers. One transport may support both patterns, but the design intent still matters.
Replay vs retry: Retry usually concerns recent uncertain handling. Replay is deliberate historical reprocessing, often for rebuild or recovery. Replay blast radius is usually larger.
Projection vs source of truth: A projection is derived state shaped for use. The source of truth is the authoritative record from which that state is derived. Confusing the two creates dangerous operational assumptions.
Backward compatibility vs forward compatibility: Backward compatibility protects older consumers from newer producers. Forward compatibility protects newer consumers reading older retained events.