SYSTEM Cited by 4 sources

Cloudflare Queues

Cloudflare Queues is Cloudflare's messaging primitive on the Developer Platform: producers write messages from Workers, a configured consumer Worker receives batches with tunable size and timeout, and the queue handles delivery + retry + dead-lettering. Documented at developers.cloudflare.com/queues.

Role

• Decoupling — producer Workers don't block on the consumer.
• Batching as throughput-amortisation — the max_batch_size × max_batch_timeout two-knob trigger lets a consumer Worker drain N messages per invocation and bulk-process them (canonical use: bulk-write to D1 / external DBs / external APIs).
• Per-region partitioning — by convention, queues are named per-region (-weur, -eeur, -wnam, etc.) when the consumer's downstream is a regionally-sharded substrate (e.g. D1 with location hints).

Canonical config (from Browser Run, 2026-05-13)

{
    "queues": {
        "consumers": [
            {
                "queue": "production-core-containers-queue-weur",
                "max_batch_size": 100,
                "max_batch_timeout": 1,
                "max_retries": 1
            }
        ]
    }
}

The two batching knobs (max_batch_size: 100, max_batch_timeout: 1 second) are the load-bearing primitives for the queue-batching-amortizes-db-write-throughput pattern — the consumer drains either when 100 messages are buffered or when 1 second elapses, whichever fires first.

Seen in

• sources/2026-05-13-cloudflare-browser-run-now-running-on-cloudflare-containers-its-faster — canonical wiki instance for Queues as a DB-write throughput multiplier. Browser Run runs ~thousands of containers per location, each updating its state every 5 seconds; without batching, the per-row D1 write rate caps the per-location ceiling at ~5,000 containers (1 ms / row × 1,000 writes/sec). Queues at max_batch_size: 100, max_batch_timeout: 1 makes each consumer drain a 100-row batch which D1 commits at P95 0.1 ms — the same wall-clock cost as a single-row write — lifting the per-location ceiling to 500,000 containers (a 100× headroom multiplier) at <2-second steady-state lag. Same post canonicalises a paired backup-region fallback for the case when a primary queue's lag exceeds the staleness budget — the queue's job is allocation-control-plane freshness, not data-plane carrying-over.
• sources/2026-09-11-cloudflare-introducing-automatic-remediation-policies-with-casb — Queues as the orchestration-message transport in CASB automatic remediation: the findings engine enqueues an orchestration message per finding; a consumer Worker pulls it and matches it against policy config before handing matched jobs to a Workflows remediation pipeline. Queue here is the event-driven decoupler between detection and action (patterns/closed-loop-remediation), not a batching amortiser.
• sources/2026-10-01-cloudflare-announcing-cloudflare-k2-serverless-event-streams — Queues as the sibling contrast to K2. The K2 launch post draws the line explicitly: Queues "are designed around tracking individual items of expensive or time consuming work … They support complex logic on the grain of a particular work item, like retries, delays, and dead-letter queues for failed attempts." K2, by contrast, "is designed for high-scale data movement, long-term retention, and fan-out consumption. Messages are produced and consumed as batches — enabling efficient processing at the expense of message-level retries. This batching also drives higher producer latency than for queues." The decision rule: Queues for per-item work with message-level logic; K2 for streaming/replay/fan-out.

Related

• systems/cloudflare-workers — producer + consumer substrate.
• systems/cloudflare-d1 — canonical downstream consumer; the 100×-headroom math depends on D1's batch-write efficiency.
• systems/cloudflare-kv — sibling primitive that Queues + D1 replaced for the Browser Run hot-allocation path (Queues+D1 give transactional commit + bounded lag, KV gives edge-replicated eventual reads).
• systems/cloudflare-durable-objects — frequent producer in per-instance state-update pipelines.
• systems/cloudflare-k2 — sibling Developer-Platform async primitive; batch-grained streaming + fan-out + long retention vs Queues' per-work-item retries/delays/DLQ.
• systems/cloudflare-browser-rendering — canonical wiki consumer in the Browser Run state-tracking pipeline.
• queue-batching-amortizes-db-write-throughput — the pattern Queues is the canonical Cloudflare-platform substrate for.
• region-fallback-on-queue-backlog — the backup posture for queue-fed control planes.
• revocation-replay-queue — Queues used as durable capture for OAuth revocation events during the Ory Hydra 2.x blue-green database migration (Source: sources/2026-06-24-cloudflare-oauth-for-all).
• companies/cloudflare — operator.