starter.wikiSearch⌘K

Infrastructure

Message Queues

Choose a message transport by delivery model, ordering, duplicate handling, consumer ownership, broker semantics, and platform boundary.

Recommendation

Choose the delivery contract before the queue product.

Pull queues, Workers-native queues, HTTP push delivery, and enterprise brokers expose different consumer, routing, ordering, and recovery behavior.12

For: Application and integration teams decoupling producers from asynchronous consumers

Main trade-off

A queue decouples producers and consumers while adding duplicate handling, ordering limits, backpressure, consumer operations, observability, and platform coupling.12

Four message transport models

The queue decision begins with how consumers receive messages and which semantics are actually required.

  1. Delivery semantics

    Define at-least-once behavior, ordering, deduplication, acknowledgement, visibility, retry, retention, and dead-letter needs.3

  2. Consumer model

    Choose polling workers, runtime-native consumers, HTTP endpoints, or broker subscriptions and assign scaling ownership.2

  3. Routing and scale

    Model fan-out, topics, sessions, throughput, message size, backpressure, hot partitions, and regional behavior.4

  4. Platform boundary

    Decide whether AWS, Cloudflare, HTTP, or Azure coupling is acceptable and plan observability, failure recovery, and exit.2

Queue routes

Select the narrowest transport contract that satisfies delivery and consumer requirements.

AWS applications need a managed pull queue

Evaluate Amazon SQS.

Standard and FIFO queues integrate with AWS identity, monitoring, and consumer services.

Verify: Consumers remain responsible for duplicate-safe processing, visibility, scaling, and failure handling.12

Workers producers and consumers need a native queue

Evaluate Cloudflare Queues.

Platform-native production and consumption can reduce assembly for Cloudflare applications.

Verify: Provider-neutral consumers, richer broker behavior, or another runtime should move the route.12

Consumers are serverless HTTP endpoints

Evaluate Upstash QStash.

Signed HTTP push, delay, and retry avoid continuously running polling workers.

Verify: Pull consumption, strict broker semantics, complex routing, or event streaming require another model.123

Enterprise messaging semantics are required

Evaluate Azure Service Bus.

Queues, topics, subscriptions, sessions, and broker controls fit richer Azure integration workloads.

Verify: A basic queue is simpler when these semantics and Azure integration do not create material value.124

Boundary: Background Jobs owns execution and workflow recovery. Cron & Scheduled Jobs owns time triggers. Replayable event-stream platform selection is outside this Task.

Transport is not execution

A queue controls message delivery; the application still owns correct processing and business recovery.

Consumption
Polling, runtime callbacks, HTTP push, and broker subscriptions create different scaling and failure paths.4
Guarantees
Duplicates, ordering, acknowledgement, redelivery, retention, and dead-letter behavior require explicit design.1
Routing
Point-to-point queues, topics, subscriptions, sessions, and HTTP endpoints are not interchangeable.4
Ownership
Consumer compute, idempotency, monitoring, backpressure, replay, and incident recovery remain application concerns.1

Official resources

Use the primary documentation to verify runtime behavior, operating limits, service boundaries, and current commercial terms.

Sources

Official documentation supporting the routes and decision boundaries on this page.

  1. 1
    Amazon SQS developer guide

    Amazon Web Services · Accessed Official

  2. 2
    Cloudflare Queues documentation

    Cloudflare · Accessed Official

  3. 3
    Upstash QStash queues

    Upstash · Accessed Official

  4. 4
    Azure Service Bus overview

    Microsoft · Accessed Official