English for Event-Driven Architects: The Vocabulary You Need

If you work on distributed systems — or want to — you’ll quickly encounter a dense vocabulary around events, messaging, and asynchronous architecture. Engineers who can talk about event-driven systems clearly are the ones who lead design reviews, shape architectural decisions, and write the proposals that get approved.

This guide covers the vocabulary that comes up most in event-driven engineering conversations: in architecture reviews, pull request discussions, Kafka runbooks, and incident post-mortems.

Event Storming Vocabulary

Event Storming is a collaborative workshop technique for mapping complex business domains using colored sticky notes on a wall (or virtual board). If you’re invited to one, you need to know the vocabulary — fast.

The core building blocks:

Domain event (orange) — something that happened in the past, named in past tense: OrderPlaced, PaymentFailed, ShipmentDispatched. Domain events are the backbone of the session.
Command (blue) — an action that triggers an event: PlaceOrder, ProcessPayment. Commands are intentional; events are facts.
Policy (purple, also called “reaction”) — a rule that automatically reacts to an event and issues a command: “Whenever OrderPlaced → send ConfirmEmail command.” In discussion you’ll hear: “There’s a policy here — whenever a payment fails, we automatically trigger a retry command.”
Aggregate (yellow) — a cluster of domain objects treated as a single unit. Commands go to an aggregate; the aggregate decides whether to accept or reject, then emits an event.
Hotspot (red) — a conflict, risk, or unresolved question raised during the session. In real workshops: “We’ve got a hotspot here — nobody’s sure who owns this event.”

In conversation during a workshop:

“Let’s keep naming domain events in past tense — ShipmentDispatched, not Dispatch Shipment. That’s a command.”

“Who’s the aggregate that accepts this command? Is it the Order or the Inventory?”

“There’s a policy gap here: what triggers the ReserveInventory command when an order is placed?”

Domain Events

Once you leave the workshop and move into implementation, the vocabulary shifts but the precision stays.

A domain event is an immutable record that something happened. Two competing styles you’ll hear debated:

Fat event (also called event-carried state transfer) — the event payload contains all or most of the data a consumer needs. No extra API call required. “We went with fat events — consumers don’t need to call back to the order service.”
Thin event (also called notification event) — the event carries only an ID and type; consumers must query the source service for details. “We kept events thin intentionally — it keeps the payload small and avoids coupling consumers to our schema.”

Naming conventions matter in English-language codebases. The standard: past-tense PascalCase using the ubiquitous language of the domain — the shared vocabulary agreed between engineers and business stakeholders. Examples: OrderShipped, UserDeactivated, InvoiceOverdue.

In code reviews you’ll see comments like:

“This event should be past-tense — ProductPriceUpdated, not UpdateProductPrice. The latter sounds like a command.”

“Are we using the ubiquitous language here? The business team calls it a ‘dispatch’, not a ‘shipment’.”

Schema evolution is a constant concern as systems grow. You’ll hear:

“We need a backward-compatible change here — add a field, don’t remove one. Our consumers can’t all deploy simultaneously.”

“We’re using schema registry with Avro. Any breaking change requires a new schema version and a migration plan.”

The term consumer contract (or consumer-driven contract) refers to an agreement — sometimes encoded as a test — that specifies what a downstream consumer expects from an event schema. “Before you change that event, run the consumer contract tests.”

Event Sourcing & CQRS

Event Sourcing is a persistence pattern where the state of an entity is not stored directly — instead, a complete log of events that produced that state is stored. The current state is derived by replaying the event log.

Key vocabulary in design discussions:

Event store — the append-only database where events are persisted. “We’re using EventStoreDB as our event store — no UPDATE or DELETE, only appends.”
Projection (also called read model) — a derived view built by processing events, optimised for queries. Projections are eventually consistent with the event store. “The order summary page reads from a projection, not the event store directly.”
Event replay — replaying stored events to rebuild a projection or recover from a bug. “There was a bug in the projection logic. We fixed the bug and replayed the event stream from scratch to rebuild the read model.”

CQRS (Command Query Responsibility Segregation) often accompanies Event Sourcing. The pattern separates writes (commands) from reads (queries) into different models — sometimes different services or databases.

In architecture discussions:

“On the write side, commands go to the aggregate and produce events. On the read side, we have projections optimised for the UI.”

“CQRS adds operational complexity — you’re managing two models. We only introduced it where the read and write loads were genuinely asymmetric.”

GDPR creates a challenge for event-sourced systems: if you can’t delete data from an immutable log, how do you honour a right-to-erasure request? The solution is crypto-shredding: encrypting personal data fields with a per-user key, then deleting the key. The event remains in the store but the personal data becomes inaccessible. “We handle GDPR by crypto-shredding — encrypt PII with the user’s key, delete the key on erasure request.”

Saga Pattern

The saga pattern solves a fundamental distributed systems problem: how do you maintain data consistency across multiple services without a distributed transaction (which would require locking across services and is impractical at scale)?

A saga is a sequence of local transactions. Each step publishes an event or message to trigger the next. If a step fails, the saga issues compensating transactions — reverse operations designed to undo the effect of earlier steps.

The critical phrase: compensating transactions provide semantic rollback, not a true database rollback. You can’t un-send an email — but you can send a cancellation email. You can’t un-charge a card — but you can issue a refund. Engineers use this language precisely:

“This is a compensating transaction — it doesn’t literally undo the database write, it undoes the business effect.”

“What’s the compensating transaction for ReserveInventory? It should be ReleaseReservation.”

Two coordination styles are debated constantly:

Choreography — each service reacts to events from other services; no central coordinator. “We used choreography here — services are fully decoupled, each one just listens for the events it cares about.”
Orchestration — a central saga orchestrator explicitly calls each service in sequence and handles failures. “After two outages caused by choreography complexity, we switched to an orchestrated saga. There’s more central coupling, but the failure paths are obvious and testable.”

The Outbox Pattern solves the dual-write problem: how do you atomically write to your database and publish a message to your broker? The solution — write both to the database (the business record and the outgoing message in an “outbox” table), then a separate process reads the outbox and publishes to the broker:

“We use the transactional outbox pattern to ensure exactly-once delivery into the broker. The outbox reader is idempotent.”

“Without the Outbox, you risk the database write succeeding but the event never being published — or vice versa.”

Temporal coupling is the risk that saga steps implicitly depend on timing or ordering even in a supposedly decoupled architecture. “There’s temporal coupling hidden here — step C assumes step B has already completed, even though there’s no explicit dependency.”

Message Broker Vocabulary

Whether you’re using Kafka, RabbitMQ, AWS SQS/SNS, or Google Pub/Sub, the foundational vocabulary overlaps.

Kafka-specific terms that appear in almost every conversation:

Topic — a named, partitioned log where events are published. “All order events go to the order-events topic.”
Partition — a topic is divided into partitions for parallelism and scalability. Events within a partition are ordered. “We partition by customerId to guarantee order for a single customer’s events.”
Consumer group — a group of consumers that together read all partitions of a topic, each partition assigned to exactly one group member. Used for competing consumers (load balancing). Not to be confused with fan-out, where multiple independent consumer groups each get a full copy of every message.

“For the notification service and the analytics service each needing every event, we use separate consumer groups — that’s fan-out.”

“For horizontal scaling within the notification service itself, multiple instances share one consumer group — that’s competing consumers.”

Dead-letter queue (DLQ) — a queue or topic where messages that cannot be processed (after retries are exhausted) are moved for inspection. “Check the DLQ — there are 47 messages stuck there from last night’s deploy.”

Delivery semantics — how many times a message is delivered:

At-most-once — messages may be lost but never duplicated. Acceptable for metrics or logs where loss is tolerable.
At-least-once — messages are never lost but may be delivered more than once. The most common default; consumers must be idempotent.
Exactly-once — each message is processed exactly once. Kafka supports this with transactions; it carries performance cost. “We use exactly-once semantics on the payment pipeline. Everywhere else, at-least-once with idempotent consumers.”

Log retention model vs. queue model — a key architectural difference. A queue (SQS, RabbitMQ) deletes messages after consumption. Kafka retains the log for a configured period (default: 7 days), allowing consumers to replay from any offset. This is central to the Event Sourcing + Kafka architecture:

“Kafka’s log retention model means new consumers can replay historical events. With SQS, that’s impossible — consumed messages are gone.”

Architecture Discussion Language

Beyond individual terms, being able to argue for or against an architecture in English is a career-differentiating skill.

Proposing EDA:

“I’d suggest we consider an event-driven approach here. Services publish domain events; consumers react asynchronously. The benefit is loose coupling — the order service doesn’t need to know which downstream services exist.”

“This is a good candidate for EDA because the coupling between these two services is causing deployment friction. Decoupling via events would let each team release independently.”

Justifying eventual consistency:

“We’re okay with eventual consistency here — the user doesn’t need to see the updated balance in real time. We can display a ‘processing’ state and update the UI when the event arrives.”

“The trade-off is that reads can be stale. We’ve made that product decision explicitly — the business accepted it because the latency improvement was worth it.”

Discussing decoupling benefits:

“The producer has no knowledge of its consumers — it just publishes the event. If we add a new analytics pipeline, the order service doesn’t change at all.”

“One benefit of going event-driven is independent deployability. The shipping service and the billing service can ship on different schedules.”

Proposing a migration strategy:

“I’d recommend the strangler fig pattern. We don’t rewrite the monolith — we route new features through the event-driven layer and gradually migrate existing flows.”

“We can start with a read-only consumer — subscribe to events and populate a new data store without touching the existing system. Once we validate it, we flip the switch.”

Discussing failure modes:

“The risk with choreography at this scale is cascade failures — one service falls behind on its queue, events back up, and the whole chain degrades.”

“We should build in back-pressure handling. If the consumer can’t keep up, we need the broker to signal that — otherwise we just grow the lag silently.”

Putting It Into Practice

The vocabulary above is useless if you can’t deploy it under pressure — in a live design review, during a job interview, or when something breaks at 2am and you’re on a call with four senior engineers.

The fastest way to build fluency is to use terms in context, get corrected, and use them again. Working through exercises that simulate real engineering conversations is more effective than just reading definitions.

To practice this vocabulary with immediate feedback, work through the EDA Language exercises — covering Event Storming terms, Event Sourcing, saga patterns, message broker vocabulary, and architecture discussion phrases.