Core Messaging Patterns

Messaging patterns shape the architecture long before anyone debates vendor choice. A queue, a topic, and an immutable stream can all move bytes, but they imply different assumptions about fan-out, work distribution, replay, and dependency shape. Chapter 4 compares those patterns directly so readers can choose the right communication model for the workload instead of treating all asynchronous transport as the same thing.

Read the lessons in order. The first covers publish-subscribe as the classic one-to-many eventing model. The second separates work queues from true fact distribution. The third explains streams and immutable logs, especially why retention and replay change architecture meaningfully. The fourth covers request-reply over messaging and why it should be treated as a deliberate pattern rather than a disguised default.

If a system uses asynchronous infrastructure everywhere but teams still argue about whether a given flow is pub/sub, background work, replayable history, or just RPC hidden behind a broker, Chapter 4 is the place to clean up that decision model.

In this section

• Publish-Subscribe
  A practical lesson on publish-subscribe as the core one-to-many eventing pattern, including where it works well and where governance becomes difficult.
• Work Queues and Background Processing
  A practical lesson on queue-based work distribution, how it differs from fact-based eventing, and where background processing is the right pattern.
• Event Streams and Immutable Logs
  A practical lesson on append-only streams, retention, replay, ordered partitions, and why durable history changes event-driven architecture significantly.
• Request-Reply Over Messaging
  A practical lesson on asynchronous request-reply flows, correlation IDs, response channels, and the risks of rebuilding synchronous RPC through a broker.