Choosing a Messaging Pattern

Every messaging pattern is a variation on one of three interaction styles — pub/sub fan-out, point-to-point work distribution, or request/reply round-trips — tuned to a particular delivery guarantee. Choosing a pattern is really two questions: what shape is the conversation, and how much can you afford to lose. Answer those and the pattern falls out.

Decision Guide

Answer a few questions to find the right messaging pattern for your use case.

Decision Flowchart

The same logic as a flowchart. The first fork is the interaction style (does the sender wait for a reply?); the second is the delivery guarantee (can a message be lost?).

Decision flowchart: the first fork is whether the sender waits for a reply, the second is whether a message can be lost, and the leaves are the five patterns.

The two branches map straight onto the Fundamentals:

• The sender waits → request/reply. Commands and Queries are the there-and-back style. Commands carry a write that returns only success/failure; Queries carry a read that returns a full body.
• The sender hands off and moves on → pub/sub or point-to-point. Now the delivery guarantee decides: at-most-once fire-and-forget (Events), or persisted delivery you can replay (Events Store). If each message must be handled by exactly one worker, that is point-to-point work distribution (Queues).

Pattern Comparison

When to Use Each Pattern

Events — Real-Time Broadcasting

Pub/sub fan-out with at-most-once delivery. Best for real-time notifications, log streaming, live dashboards, and cache invalidation where occasional message loss is acceptable.

Trade-offs: Fastest (no disk I/O), but messages are lost if no subscriber is connected — there is no acknowledgement and nothing to replay.

Events: the publisher fires once, every connected subscriber gets the message, and anyone offline simply misses it.

Events Store — Persistent Pub/Sub

Pub/sub fan-out with at-least-once delivery, persisted to disk. Best for audit trails, event sourcing, cross-service state sync, and any scenario where messages must not be lost.

Trade-offs: Higher latency than Events (disk I/O), but subscribers can replay from any point — a late subscriber can read the whole history.

Events Store: messages are persisted to disk as they are delivered live, so a subscriber that connects later can replay the full history.

Queues — Work Distribution

Point-to-point competing consumers with exactly-once processing. Best for order processing, background jobs, webhook delivery, and any task where each message must be handled by exactly one worker.

Trade-offs: Requires an explicit ack/nack, but in return you get the full reliability toolkit — DLQ, delayed delivery, visibility timeout, and retry.

Queues: one consumer receives the message and acknowledges it, and only then is the message removed from the queue.

RPC — Request/Reply

The there-and-back interaction style. Best for service-to-service communication, API gateways, CQRS, and device command/control.

Trade-offs: Synchronous (sender blocks), but provides a direct response. Commands strip the response body (write semantics), Queries preserve it (read semantics).

RPC: the sender blocks while KubeMQ routes the request to a responder and returns the single response back.

Combining Patterns

Real systems rarely pick one pattern. The same message often fans out across several styles at once — broadcast for visibility, queue for reliable work. KubeMQ does this with channel routing: one send, multiple destinations.

Event-Driven with Work Queue

Broadcast events for monitoring (pub/sub, loss OK), and route critical work to a queue for reliable point-to-point processing.

Event-driven with work queue: a single send fans out to a dashboard for monitoring and to a queue for reliable point-to-point processing.

CQRS with Events

Commands write data (request/reply), events propagate the change (pub/sub), queries read projections (request/reply).

CQRS with events: commands write through the event store, the read service subscribes to build projections, and clients query that read side.

Fan-Out with Routing

Publish once, deliver to multiple patterns using channel routing syntax.

Decision Matrix