A practical lesson on the transport vocabulary of event-driven systems and the differences between fan-out, work distribution, and durable event flow.
Transport vocabulary in event-driven systems is easy to misuse because different tools expose overlapping words. Teams say “queue,” “topic,” “stream,” or “event bus” as if they all mean the same thing, then build architectures with unclear delivery expectations. The result is usually not an infrastructure failure first. It is a modeling failure: one team expects fan-out, another expects work distribution, and a third assumes replay exists because someone called the platform an event bus.
The safest approach is to tie each term to the delivery shape it implies.
flowchart TD
A["Broker"] --> B["Topic or pub/sub path"]
A --> C["Queue or work-distribution path"]
A --> D["Stream or durable log path"]
B --> E["One event to many interested consumers"]
C --> F["One work item to one worker at a time"]
D --> G["Retained ordered history with replay potential"]
What to notice:
A broker is the infrastructure that accepts, stores, routes, and delivers messages or events. It may support several delivery styles at once. The broker itself is not the event-driven architecture. It is the transport substrate that makes those patterns possible.
This matters because teams sometimes discuss the broker as if it explains the system. It does not. A platform can have an excellent broker and still have weak event contracts, poor retry handling, or badly shaped consumer boundaries.
Topics usually support publish/subscribe behavior. A producer publishes a message or event once, and several consumers or consumer groups may receive it independently. Topics are strong when one meaningful fact should fan out to several downstream concerns such as projections, alerts, and workflows.
Topics are weaker when the real need is to distribute one unit of work among many workers. Using a topic when only one consumer should act can produce duplicated effort or unnecessary coordination.
Queues usually support work distribution. A work item is delivered so one worker or one worker instance handles it at a time. This is excellent for background processing, rate smoothing, and worker pools. It is often confused with general event-driven architecture because the transport still looks asynchronous.
The confusion matters because queue-based work distribution is not automatically the same as business-fact fan-out. One says “do this work.” The other says “this fact happened.”
Streams are durable logs with retention and usually some notion of ordered partitions. They are especially useful when replay, rebuilding projections, or maintaining longer-lived event history matters. This changes architecture significantly because historical events remain operationally relevant.
If a system depends on replay, then contract quality, schema discipline, and safe reprocessing matter much more than in a short-lived transient queue.
1transportChoices:
2 order-events:
3 kind: topic
4 purpose: fan-out to projections and workflows
5 invoice-jobs:
6 kind: queue
7 purpose: distribute background work
8 audit-stream:
9 kind: stream
10 purpose: retained history and replay
The reader should notice that the transport kind is tied to the delivery goal, not chosen arbitrarily.
An event bus is an architectural abstraction: a shared mechanism that allows producers and consumers to exchange events. It is useful at the diagram level because it expresses that events can move across bounded components without direct point-to-point wiring. But it is too vague to be the whole explanation. Reviewers still need to know whether each path behaves like a topic, queue, stream, or some hybrid.
If a diagram shows only one “event bus” box and dozens of arrows, the design probably still needs transport detail before anyone can reason about ordering, replay, or failure.
queue and topic as interchangeable wordsevent busAn architecture review shows one central “event bus” with many consumers, but nobody can say which flows are one-to-many fan-out and which are single-consumer work queues. Why is that a serious gap?
Because delivery shape determines correctness assumptions. Without knowing whether a path is pub/sub, queue-based work distribution, or replayable stream retention, teams cannot reason clearly about duplicates, ordering, failure handling, or consumer responsibility.