Messaging Patterns Explained: System Design

In a nutshell

Competing consumers and priority queues spread and order work; pipes and filters split processing into stages.
Claim check keeps big payloads out of the message: store the data, send a reference.
Sequential convoy keeps related messages in order without serialising everything.
Choreography lets services react to each other's events without a central controller.

Publisher-subscriber and competing consumers

Publisher-subscriber: a sender publishes an event once and every interested subscriber gets a copy (covered in depth in Pub/Sub and event streaming). Competing consumers: several workers read from the same queue, each message going to one of them, so throughput scales with the number of workers.

Use when: work arrives faster than one worker handles it, and messages can be processed independently and idempotently.

Priority queue

Some messages matter more: a password-reset email should not wait behind a million newsletter emails. Either use a broker that supports message priorities, or (more common and more predictable) use separate queues per priority with more consumers on the high-priority one.

Separate queues per priority

High-priority messages get their own queue and more workers, so bulk work never delays them.

Diagram as text

Producers → High priority
Producers → Low priority
High priority → 8 workers
Low priority → 2 workers

Pipes and filters

Break a complex job into independent filters (stages) connected by pipes (queues): an uploaded image is validated, then virus-scanned, then resized, then watermarked. Each stage scales and fails on its own, and stages can be reused or reordered.

An image pipeline

Each stage reads from one queue and writes to the next. A slow stage gets more workers without touching the others.

Diagram as text

Validate → Scan: queue
Scan → Resize: queue
Resize → Watermark: queue

Claim check

Message brokers limit message size (Amazon SQS allows 256 KB per message) and large messages slow everything down. Store the payload in object storage and send only a small message with its key (the claim check). The consumer fetches the payload when it needs it.

Sequential convoy

Messages for the same entity must be processed in order (order created, then paid, then shipped), but different entities can be processed in parallel. Group messages by a key (Kafka partitions keyed by order ID, SQS FIFO message groups, Azure Service Bus sessions), so each group is handled in order by one consumer at a time.

Asynchronous request-reply

For work that takes longer than a client will wait: accept the request with 202 Accepted and a status URL, process it in the background, and let the client poll the status URL (or receive a callback) until the result is ready. See the Task queues topic for a full walk-through.

Scheduler agent supervisor

A scheduler runs the steps of a long workflow, agents wrap calls to each remote service (with retries and timeouts), and a supervisor watches for steps that stalled or failed and retries or compensates them. Workflow engines such as Temporal, AWS Step Functions and Azure Durable Functions package this pattern.

Choreography

Instead of an orchestrator telling each service what to do, each service listens for events and reacts: Orders publishes order.placed, Inventory reserves stock and publishes stock.reserved, Payments charges and publishes payment.completed. No central component, so services stay loosely coupled; the cost is that the overall flow is spread across services and harder to follow. Orchestration vs choreography is compared in the Distributed transactions topic.

Pattern	Problem it solves
Publisher-subscriber	Many consumers need the same event
Competing consumers	Too much work for one worker
Priority queue	Urgent work stuck behind bulk work
Pipes and filters	A big job with separable stages
Claim check	Payloads too large for the broker
Sequential convoy	Per-entity ordering with overall parallelism
Async request-reply	Clients cannot wait for long work
Scheduler agent supervisor	Long workflows that must survive failures
Choreography	Coordinating services without a central controller

Common mistakes

Putting large files inside messages instead of using a claim check.
Using one queue for everything, so bulk jobs delay urgent ones.
Expecting global order when only per-entity order is needed (or available).
Building a long choreographed flow that nobody can trace end to end.

Interview questions

Try answering out loud before you open each one.

Password-reset emails are delayed during a newsletter send. Fix it.

Separate queues by priority: transactional emails on their own queue with dedicated workers, bulk sends on another with limited workers and rate limits. Monitor queue age for the transactional queue and alert if it grows.

Your notes

Saved in this browser as you type.

Finished this topic?

Mark it read to track your progress, then carry on with the next one.

Next topic