6 Cloud Messaging Patterns

Cloud messaging patterns exist because direct synchronous calls are not always the right contract. Some workloads need buffering, some need fan-out, some need ordered background execution, and some need long-running coordination across services. The pattern matters because it decides who waits, who retries, and where failure is absorbed.

1. Asynchronous request-reply

Use asynchronous request-reply when a client needs to start work now but the result will take longer than a normal HTTP request should remain open. The usual shape is an API that accepts the request, returns HTTP 202 Accepted with a job identifier, and lets the client poll a status endpoint or receive a callback later.

This protects the frontend from backend latency and gives the server room to queue, retry, or fan work out internally. The main design work is around status tracking. Clients need a stable job state model such as queued, running, succeeded, or failed.

2. Publisher-subscriber

Publisher-subscriber decouples producers from consumers. A producer publishes an event once, and multiple subscribers can react independently. This is useful when one business event should drive analytics, notifications, billing, and search indexing without forcing the originating service to call every downstream system directly.

The benefit is loose coupling and easy fan-out. The cost is weaker visibility into who depends on an event and what guarantees each subscriber expects. Schema changes also need compatibility discipline because several systems may be reading the same stream.

3. Claim check

Claim check handles messages that are too large or too expensive to push through the broker directly. Instead of sending the full payload, the producer stores it in external storage such as object storage or a database and places only a reference on the queue.

This keeps the broker fast and avoids blowing up message size limits. It is common for document processing, media pipelines, and large report generation. The tradeoff is that the workflow now depends on two systems: the broker for coordination and the blob store for payload retrieval. Reference expiry, access control, and cleanup of orphaned payloads become part of the design.

4. Priority queue

A priority queue lets urgent work jump ahead of routine work. This is useful when all tasks are not equal, for example fraud checks versus nightly exports, or customer-visible actions versus best-effort maintenance jobs.

The pattern works only if priorities are chosen carefully. Too many high-priority messages turn the system back into a normal queue, while a permanent stream of urgent items can starve lower-priority work. Teams often add quotas, ageing, or separate worker pools so important background work still completes under sustained pressure.

5. Saga

Saga is a messaging pattern for coordinating a business transaction that spans several services, each with its own local database. Instead of a distributed transaction, the system performs a sequence of local steps and, if one step fails, runs compensating actions to undo or offset earlier work.

This is useful for workflows such as order placement, where payment, inventory, and shipping all change state independently. The hard part is that compensation is not a database rollback. It is new business logic that may itself fail or encounter time-based constraints.

6. Competing consumers

Competing consumers put several workers on the same queue so messages can be processed in parallel. This improves throughput and gives natural horizontal scaling for independent tasks such as image resizing, email sending, or invoice generation.

The key limitation is ordering. Once several consumers are pulling from the same queue, global ordering is usually gone unless the broker adds partition rules and the workload is carefully keyed. Duplicate delivery and poison messages also matter more because one bad message can repeatedly occupy worker capacity until it is retried, delayed, or dead-lettered.

These patterns are often combined. A system might accept work through asynchronous request-reply, publish follow-up events through pub-sub, store large artefacts with claim check, and process internal tasks with competing consumers. The important design decision is the operational contract each pattern creates around latency, retries, ordering, and failure recovery.