Cloudflare Queues là gì? Hàng đợi message để Worker không phải làm hết trong một request What are Cloudflare Queues? A message line so a Worker does not do everything in one request What are Cloudflare Queues? A message line so a Worker does not do everything in one request

Vì sao không nhét mọi việc vào một request Worker? Why not stuff every job into one Worker request? Why not stuff every job into one Worker request?

Một form đăng ký workshop, một webhook thanh toán, hay một lần upload ảnh thường kích hoạt nhiều việc phụ: ghi database, gửi email, resize ảnh, gọi API bên thứ ba. Nếu Worker làm hết trong request của người dùng, họ phải chờ, và một bước chậm có thể làm cả request timeout. Người dùng chỉ cần biết “đã nhận”, không cần đứng đợi email đi xong. A workshop signup, a payment webhook, or an image upload often kicks off side work: write the database, send email, resize the image, call a third-party API. If the Worker does all of that inside the user’s request, they wait, and one slow step can time the whole request out. The user only needs “we received it”, not to stand there until the email has gone. A workshop signup, a payment webhook, or an image upload often kicks off side work: write the database, send email, resize the image, call a third-party API. If the Worker does all of that inside the user’s request, they wait, and one slow step can time the whole request out. The user only needs “we received it”, not to stand there until the email has gone.

Cloudflare Queues là dịch vụ hàng đợi message toàn cầu trên nền tảng Workers. Worker producer gửi một message (ví dụ `{ signupId: "abc" }`) vào queue qua binding. Consumer — thường là một Worker khác — nhận message theo lô và xử lý khi sẵn sàng. Tài liệu chính thức mô tả đây là hàng đợi có guaranteed delivery: message không biến mất chỉ vì consumer đang bận một lúc. Cloudflare Queues is a global message queue on the Workers platform. A producer Worker sends a message (for example `{ signupId: "abc" }`) through a binding. A consumer — usually another Worker — receives messages in batches and processes them when it is ready. Official docs describe guaranteed delivery: a message does not vanish just because the consumer is busy for a moment. Cloudflare Queues is a global message queue on the Workers platform. A producer Worker sends a message (for example `{ signupId: "abc" }`) through a binding. A consumer — usually another Worker — receives messages in batches and processes them when it is ready. Official docs describe guaranteed delivery: a message does not vanish just because the consumer is busy for a moment.

Hãy hình dung quầy bánh mì giờ cao điểm. Khách lấy số và đi. Bếp xử lý từng mẻ, không bắt khách đứng trong bếp. Queues tách “nhận việc” khỏi “làm việc”. Đó là lý do các bài trên blog.cloudflare.com về Workers và hàng đợi thường đặt Queues cạnh webhook, email, và pipeline — không phải cạnh cache tĩnh. Picture a bakery at rush hour. Customers take a number and leave. The kitchen works in batches and does not make customers stand in the kitchen. Queues split “accept the job” from “do the job”. That is why Cloudflare Blog posts on Workers and queues place Queues next to webhooks, email, and pipelines — not next to static cache. Picture a bakery at rush hour. Customers take a number and leave. The kitchen works in batches and does not make customers stand in the kitchen. Queues split “accept the job” from “do the job”. That is why Cloudflare Blog posts on Workers and queues place Queues next to webhooks, email, and pipelines — not next to static cache.

Producer, consumer, và hai cách lấy message Producer, consumer, and two ways to take messages Producer, consumer, and two ways to take messages

Producer là Worker gửi message. Bạn khai báo binding trong cấu hình Wrangler, ví dụ tên binding `SIGNUPS`, rồi gọi `env.SIGNUPS.send(payload)`. Có thể đặt `delivery_delay` để message chưa hiện ra cho consumer ngay — hữu ích khi bạn muốn chờ vài chục giây cho giao dịch hoàn tất trước khi gửi email. Một Worker có thể vừa produce vừa consume nhiều queue. The producer is the Worker that sends the message. You declare a binding in Wrangler, for example `SIGNUPS`, then call `env.SIGNUPS.send(payload)`. You can set a `delivery_delay` so the message is not visible to the consumer yet — useful when you want a few dozen seconds for a transaction to finish before the email goes out. One Worker can produce to and consume from several queues. The producer is the Worker that sends the message. You declare a binding in Wrangler, for example `SIGNUPS`, then call `env.SIGNUPS.send(payload)`. You can set a `delivery_delay` so the message is not visible to the consumer yet — useful when you want a few dozen seconds for a transaction to finish before the email goes out. One Worker can produce to and consume from several queues.

Consumer kiểu push là cách dễ nhất để bắt đầu: Cloudflare gọi Worker của bạn với một batch message, và consumer tự scale theo lượng việc. Bạn cấu hình `max_batch_size`, `max_batch_timeout`, `max_retries`, và tùy chọn `retry_delay`. Consumer kiểu pull thì ngược lại: hệ thống bên ngoài (không nhất thiết là Workers) tự gọi HTTP để kéo message khi sẵn sàng. Tài liệu pull consumer ghi rõ mức hiện tại là tối đa 5.000 message mỗi giây trên mỗi queue — hợp khi bạn cần hãm tốc độ cho một database cũ. A push consumer is the easiest start: Cloudflare invokes your Worker with a batch, and the consumer scales with the workload. You configure `max_batch_size`, `max_batch_timeout`, `max_retries`, and optionally `retry_delay`. A pull consumer is the opposite: something outside Workers calls HTTP to pull messages only when it is ready. Pull-consumer docs currently allow up to 5,000 messages per second per queue — a fit when you must throttle into an older database. A push consumer is the easiest start: Cloudflare invokes your Worker with a batch, and the consumer scales with the workload. You configure `max_batch_size`, `max_batch_timeout`, `max_retries`, and optionally `retry_delay`. A pull consumer is the opposite: something outside Workers calls HTTP to pull messages only when it is ready. Pull-consumer docs currently allow up to 5,000 messages per second per queue — a fit when you must throttle into an older database.

Xử lý xong phải ack (acknowledge) message. Nếu bạn không ack, hoặc gọi retry, message được giao lại. Đó là at-least-once: cùng một việc có thể tới consumer nhiều hơn một lần. Code consumer phải chịu được việc đó — ví dụ ghi “email đã gửi” vào D1 trước khi gửi lại, để lần thứ hai không gửi trùng. Nếu hết `max_retries` mà vẫn lỗi, message đi vào dead-letter queue nếu bạn đã cấu hình; nếu không, message bị bỏ. When processing finishes you must acknowledge the message. If you do not ack, or you retry, the message is delivered again. That is at-least-once: the same job can reach the consumer more than once. Consumer code has to tolerate that — for example record “email sent” in D1 before sending, so the second delivery does not send a duplicate. After `max_retries` the message goes to a dead-letter queue if you configured one; otherwise it is discarded. When processing finishes you must acknowledge the message. If you do not ack, or you retry, the message is delivered again. That is at-least-once: the same job can reach the consumer more than once. Consumer code has to tolerate that — for example record “email sent” in D1 before sending, so the second delivery does not send a duplicate. After `max_retries` the message goes to a dead-letter queue if you configured one; otherwise it is discarded.

Queues khác Workflows, KV và cron như thế nào? How do Queues differ from Workflows, KV, and cron? How do Queues differ from Workflows, KV, and cron?

Cron trên Workers hợp với việc “mỗi giờ chạy một lần” theo lịch. Queues hợp với việc “mỗi sự kiện một message”, số lượng lên xuống theo traffic thật. Workflows hợp khi bạn cần nhiều bước có trạng thái, có thể sleep vài giờ rồi chạy tiếp đúng chỗ đã dừng. Queues không nhớ “bước 3 của hồ sơ này”; nó chỉ giữ message cho đến khi consumer xử lý xong hoặc hết hạn giữ. A Workers cron fits “run once an hour” on a schedule. Queues fit “one message per event”, with volume that follows real traffic. Workflows fit multi-step work with state, including sleeping for hours and resuming exactly where you stopped. Queues do not remember “step 3 of this case”; they hold a message until the consumer finishes it or retention expires. A Workers cron fits “run once an hour” on a schedule. Queues fit “one message per event”, with volume that follows real traffic. Workflows fit multi-step work with state, including sleeping for hours and resuming exactly where you stopped. Queues do not remember “step 3 of this case”; they hold a message until the consumer finishes it or retention expires.

KV là tủ tra cứu: bạn biết khóa, bạn đọc giá trị, và ghi mới có thể mất vài giây mới thấy khắp nơi. Đừng dùng KV như hàng đợi bằng cách nhét danh sách việc vào một key JSON — hai producer ghi cùng lúc sẽ đè nhau. D1 hợp để lưu kết quả đã xử lý (bảng đăng ký, trạng thái email). R2 hợp để giữ file lớn mà message chỉ trỏ tới object key, không nhét cả file vào body message. KV is a lookup locker: you know the key, you read the value, and a fresh write can take a few seconds to show everywhere. Do not use KV as a queue by stuffing a job list into one JSON key — two producers writing at once will overwrite each other. D1 fits the result after processing (the signup row, the email status). R2 fits large files, with the message pointing at an object key instead of carrying the whole file. KV is a lookup locker: you know the key, you read the value, and a fresh write can take a few seconds to show everywhere. Do not use KV as a queue by stuffing a job list into one JSON key — two producers writing at once will overwrite each other. D1 fits the result after processing (the signup row, the email status). R2 fits large files, with the message pointing at an object key instead of carrying the whole file.

Một pattern thực tế trên hub này: form workshop nhận request, ghi D1, gửi message `{ signupId }` vào queue, trả 200 ngay. Consumer gửi email xác nhận và retry nếu nhà cung cấp email lỗi. Nếu bạn đã đọc bài Workflows, hãy coi Queues là “băng chuyền việc” và Workflows là “hồ sơ nhiều bước”. Nhiều app dùng cả hai: queue nhận burst, workflow điều phối các bước dài của từng đơn. A practical pattern on this hub: the workshop form accepts the request, writes D1, sends `{ signupId }` to a queue, and returns 200 immediately. The consumer sends the confirmation email and retries if the email provider fails. If you have read the Workflows post, treat Queues as the “job conveyor” and Workflows as the “multi-step case file”. Many apps use both: the queue absorbs bursts, the workflow orchestrates the long steps of each order. A practical pattern on this hub: the workshop form accepts the request, writes D1, sends `{ signupId }` to a queue, and returns 200 immediately. The consumer sends the confirmation email and retries if the email provider fails. If you have read the Workflows post, treat Queues as the “job conveyor” and Workflows as the “multi-step case file”. Many apps use both: the queue absorbs bursts, the workflow orchestrates the long steps of each order.

Bắt đầu an toàn: checklist tuần đầu với Queues A safe start: first-week Queues checklist A safe start: first-week Queues checklist

Một: bắt đầu với một queue, một producer, một push consumer. Đặt tên message rõ (`signup.created`) và payload nhỏ, có id để tra D1. Hai: viết consumer idempotent — chạy hai lần không được gửi hai email hay trừ tiền hai lần. Ba: cấu hình dead-letter queue trước khi production, rồi xem những message nằm đó thay vì để chúng biến mất sau hết số lần retry. One: start with one queue, one producer, one push consumer. Name the message clearly (`signup.created`) and keep the payload small, with an id you can look up in D1. Two: make the consumer idempotent — running twice must not send two emails or charge twice. Three: configure a dead-letter queue before production, then inspect what lands there instead of letting messages disappear after the last retry. One: start with one queue, one producer, one push consumer. Name the message clearly (`signup.created`) and keep the payload small, with an id you can look up in D1. Two: make the consumer idempotent — running twice must not send two emails or charge twice. Three: configure a dead-letter queue before production, then inspect what lands there instead of letting messages disappear after the last retry.

Bốn: nhớ hạn giữ message. Bạn có thể chỉnh retention từ 60 giây đến 14 ngày. Trên gói Workers Free, hạn giữ tối đa là 24 giờ chứ không phải 14 ngày; free cũng gồm tới 10.000 queue và 10.000 operations mỗi ngày (đọc, ghi, xóa). Đừng thiết kế luồng “để message nằm hàng tuần” trên free. Năm: log lỗi consumer bằng Workers Logs — bài observability trên hub giải thích vì sao nhìn lỗi sớm quan trọng hơn chờ user báo. Four: remember retention. You can set it from 60 seconds up to 14 days. On the Workers Free plan the maximum retention is 24 hours, not 14 days; Free also includes up to 10,000 queues and 10,000 operations per day (reads, writes, and deletes). Do not design a flow that leaves messages sitting for weeks on Free. Five: log consumer failures with Workers Logs — the observability post on this hub explains why seeing errors early matters more than waiting for a user report. Four: remember retention. You can set it from 60 seconds up to 14 days. On the Workers Free plan the maximum retention is 24 hours, not 14 days; Free also includes up to 10,000 queues and 10,000 operations per day (reads, writes, and deletes). Do not design a flow that leaves messages sitting for weeks on Free. Five: log consumer failures with Workers Logs — the observability post on this hub explains why seeing errors early matters more than waiting for a user report.

Câu hỏi tự kiểm tra: “Nếu message này được giao hai lần, hệ thống có làm hại user không?” Nếu có, bạn chưa xong phần idempotency — đó không phải lỗi của Queues. Đọc trang sản phẩm Queues, lộ trình Developer Platform, và bài gốc trên blog.cloudflare.com khi bạn cần giới hạn kích thước message hoặc event subscriptions mới nhất. Self-check: “If this message is delivered twice, can it harm the user?” If yes, idempotency is not finished — that is not a Queues bug. Read the Queues product page, the Developer Platform track, and the original posts on blog.cloudflare.com when you need the latest message-size limits or event subscriptions. Self-check: “If this message is delivered twice, can it harm the user?” If yes, idempotency is not finished — that is not a Queues bug. Read the Queues product page, the Developer Platform track, and the original posts on blog.cloudflare.com when you need the latest message-size limits or event subscriptions.

Hình minh họa Cloudflare Cloudflare visuals Cloudflare visuals

Sơ đồ Reference Architecture chính thức và (khi có) ảnh Dashboard — giúp đối chiếu khi học. Official Reference Architecture diagrams and (when available) Dashboard screenshots — useful while you learn. Official Reference Architecture diagrams and (when available) Dashboard screenshots — useful while you learn.

Học tiếp trên hub (on-page backlinks) Keep learning on this hub (on-page links) Keep learning on this hub (on-page links)

• Queues là gì? (trang sản phẩm) What are Queues? (product page) What are Queues? (product page)
• Workers là gì? (trang sản phẩm) What are Workers? (product page) What are Workers? (product page)
• Lộ trình Developer Platform Developer Platform track Developer Platform track
• Use case: ứng dụng serverless Use case: build a serverless app Use case: build a serverless app
• So sánh với Workflows Compare with Workflows Compare with Workflows

Nguồn tham khảo (blog.cloudflare.com) Sources (blog.cloudflare.com) Sources (blog.cloudflare.com)

Nội dung được viết lại để dễ hiểu hơn; luôn đọc bài gốc trên blog.cloudflare.com và docs chính thức khi cần chi tiết kỹ thuật hoặc cập nhật mới nhất. Content is rewritten for clarity; always read the original posts on blog.cloudflare.com and official docs for technical detail or the latest updates. Content is rewritten for clarity; always read the original posts on blog.cloudflare.com and official docs for technical detail or the latest updates.

• Cloudflare Docs — Queues ↗
• Cloudflare Docs — Pull consumers ↗
• The Cloudflare Blog — Queues on the Workers Free plan ↗