demo: cloudflare queues (producer + consumer)
submit text below. the pages function puts it on a queue and returns immediately with a job id. a separate consumer worker picks up the message asynchronously, "processes" it (uppercases the text), and stores the result in kv. the page polls for the result.
expect 5-60s to first result. the consumer picks up
messages in ~1s but the result store is workers kv, which is eventually
consistent globally. depending on which colo processes the write vs.
which colo serves your poll, the result can take up to 60s to appear.
this is a real property of the platform, not a bug in the demo.
enqueue something…
# architecture
┌─────────┐ POST /api/queue-enqueue ┌─────────────┐
│ browser │──────────────────────────────→ │ pages func │
└─────────┘ └──────┬──────┘
▲ │ QUEUE.send({id, text})
│ ▼
│ ┌─────────────┐
│ poll /api/queue-status?id=... │ site-queue │ (cloudflare queues)
│◄─────────────────────────────────── └──────┬──────┘
│ pending: true / result: {} │ batched delivery
│ ▼
│ ┌─────────────────────┐
│ │ site-queue-consumer │
│ │ (worker) │
│ └──────┬──────────────┘
│ │ KV.put(job:id, result)
│ ▼
│ pages func reads KV ┌──────┐
└────────────────────────────────────────────│ KV │
└──────┘
# config
| queue | site-queue |
| producer | pages function /api/queue-enqueue (QUEUE binding) |
| consumer | worker site-queue-consumer (batch_size=10, max_retries=3) |
| result store | KV, key job:<id>, TTL 3600s |