Vocabulary for Event-Driven Systems: Producers, Consumers, Sagas, and More

Event-driven architecture (EDA) has its own dense vocabulary, and a lot of it is easy to misuse if English isn’t your first language. The words publish, emit, consume, and replay all carry precise meanings here. This guide walks through the core terms, shows how engineers actually use them in sentences, and flags the mistakes that mark you as a non-native speaker.

---

The core mental model

In an event-driven system, components don’t call each other directly. Instead, something happens — an event — and other components react to it. An event is a fact about something that already happened, written in the past tense: OrderPlaced, PaymentFailed, UserRegistered.

“When a customer checks out, the order service emits an OrderPlaced event. The shipping service reacts to it. The two services never talk directly.”

Note the tense: event names are past-tense facts, never commands. CreateOrder is a command (an instruction); OrderCreated is an event (a fact). Getting this distinction right in conversation signals real fluency.

---

Producers, consumers, and the broker

• Producer (or publisher) — the component that creates and emits / publishes events.
• Consumer (or subscriber) — the component that reads and processes events.
• Broker — the middleware that stores and routes events (Kafka, RabbitMQ, NATS).
• Topic (Kafka) or queue (RabbitMQ) — the named channel events flow through.

Common verb collocations — use these exact pairings:

• producers publish / emit / produce events
• consumers subscribe to topics and consume events
• the broker routes, buffers, and delivers events

“Three services subscribe to the payments topic. Each consumes events at its own pace.”

Mistake to avoid: non-native speakers often say “the producer sends the event to the consumer.” In EDA, the producer doesn’t know who the consumers are — say “the producer publishes an event” and “the consumer subscribes to the topic.”

---

Delivery guarantees

This is where precise English really matters, because the terms sound similar but mean very different things:

• At-most-once — events may be lost but never duplicated.
• At-least-once — events are never lost but may be duplicated.
• Exactly-once — each event is processed once (hard to achieve; often “effectively exactly-once”).

Because at-least-once is the common default, consumers must handle duplicates. That leads to the single most important word in EDA:

• Idempotent / idempotency — processing the same event twice produces the same result as processing it once.

“Our delivery is at-least-once, so every consumer has to be idempotent. We deduplicate using the event ID.”

Pronounce it eye-DEM-po-tent. Mispronouncing this word is extremely common — practise it.

---

Ordering, partitions, and offsets

• Partition — a topic is split into partitions for parallelism; order is guaranteed within a partition, not across them.
• Partition key — the field that decides which partition an event lands in.
• Offset — a consumer’s position in the stream; consumers commit offsets to record progress.
• Lag — how far behind a consumer is. “Consumer lag is spiking — we’re falling behind.”
• Replay — re-reading old events from the log, e.g. to rebuild state.

“We key by customerId so all of one customer’s events land in the same partition and stay in order. If a consumer crashes, it resumes from its last committed offset.”

---

When things go wrong

• Dead-letter queue (DLQ) — where events go after repeated processing failures.
• Poison message / poison pill — an event that always fails and blocks the queue.
• Retry with backoff — retrying after increasing delays.
• Redrive — moving events from the DLQ back for reprocessing.

“A poison message stalled the consumer. We routed it to the dead-letter queue and redrove it after fixing the bug.”

---

Sagas and distributed transactions

You can’t run a single database transaction across many services, so you coordinate with a saga: a sequence of local transactions, each emitting an event that triggers the next step. If a step fails, you run compensating transactions to undo the earlier ones.

• Orchestration — a central coordinator tells each service what to do.
• Choreography — no central brain; services react to each other’s events.
• Compensating transaction — an action that semantically undoes a previous one (e.g. refund compensates charge).

“We use a choreographed saga. If shipping fails, the payment service catches the ShipmentFailed event and triggers a compensating refund.”

Pronunciation note: saga is /ˈsɑːɡə/. Choreography is /ˌkɒriˈɒɡrəfi/ — the ch sounds like k.

---

Event sourcing vs. event streaming

These two are often confused:

• Event streaming — moving events between systems in real time.
• Event sourcing — storing state as a sequence of events; current state is derived by replaying them.
• CQRS (Command Query Responsibility Segregation) — separating the write model from the read model, often paired with event sourcing.
• Projection — a read-optimised view built by replaying events.

“With event sourcing, the event log is the source of truth. We build a projection for the dashboard by replaying the stream into a read model.”

---

Before / after: sounding fluent

Before: “The sender sends the message and the receiver gets it and if it fails it tries again.”

After: “The producer publishes the event to the topic. Consumers process it idempotently, and on repeated failure the event lands in the dead-letter queue for later redrive.”

The second version is shorter and more precise — that’s what mastering the vocabulary buys you.

---

Quick reference glossary

Term	One-line meaning
Event	A past-tense fact about something that happened
Producer / consumer	Emits events / processes events
Broker	Stores and routes events
Idempotent	Safe to process twice
Offset / lag	Consumer position / how far behind
DLQ	Where failed events go
Saga	Coordinated multi-service transaction
Compensating transaction	Undoes a previous step
Event sourcing	State stored as a log of events
CQRS	Separate read and write models

---

Key takeaways

• Events are past-tense facts; commands are instructions. Don’t mix them.
• Producers publish; consumers subscribe and consume — they don’t address each other directly.
• Idempotency is the heart of event-driven correctness — learn the word and its pronunciation.
• Sagas use compensating transactions, not rollbacks, to undo distributed work.
• Master these collocations and you’ll describe complex systems in a sentence where others need a paragraph.

In Practice: Navigating Nuances in Team Communication

Let’s be honest – even experienced developers sometimes stumble over the precise wording when discussing complex systems like event-driven architectures. It’s not just about knowing the definitions of “producer” or “saga”; it’s about communicating those concepts clearly and confidently within a team, especially when collaborating with colleagues who may have varying levels of English proficiency. A common pitfall is using overly technical jargon without considering how others will interpret it. For instance, during a code review on a new message handler, you might see a comment like: “This consumer doesn’t handle duplicate events – needs idempotency!” While technically correct, the phrasing can feel abrupt and intimidating to someone less familiar with the underlying concepts.

Consider this Slack conversation between two developers, Alex and Ben, discussing a pull request for a new order processing system built around Kafka:

Alex: “Ben, I’ve implemented the OrderCreated event producer. It reliably publishes events to the ‘orders’ topic.”

Ben: “Okay, cool. Just checking – are we using a dead-letter queue for failed orders? Seems like a good practice to avoid losing data if something goes wrong with the integration.”

The key here is that Ben’s question—about the dead-letter queue—is phrased as a suggestion or observation rather than a direct critique. It’s more approachable and invites discussion. Similarly, when writing a pull request description, avoiding overly formal language can significantly improve understanding. Instead of saying “This component ensures idempotency to prevent duplicate processing,” you could write: “This handler is designed to process each order event only once, even if it receives the same event multiple times – ensuring data consistency.”

Understanding these subtle differences in phrasing allows you to build stronger communication within your team and avoid misunderstandings that can lead to costly rework. It’s about conveying intent rather than just stating facts. Remember, clear communication is a cornerstone of successful engineering collaboration.

Here’s an example illustrating the use of kafka-console for debugging:

kafka-console --bootstrap-server localhost:9092 --topic orders --describe-group my-order-group

This command allows you to monitor the Kafka topic and group, confirming that events are being produced and consumed correctly. While this is a simple example, it demonstrates how technical vocabulary can be used in a practical context – demonstrating functionality or troubleshooting issues. It’s far more effective than simply stating “The Kafka cluster is functioning.”