คำตอบสั้น: ใช้ Queues เมื่อคุณต้องการดันงานออกจาก request path แล้วให้ retry ได้เอง คิดเงินเป็นจำนวน operation ไม่ใช่ปริมาณข้อมูล ใช้ Pipelines เมื่อคุณต้องการยิง event ปริมาณมากเข้ามา แปลงด้วย SQL แล้วเขียนลง R2 เป็น Iceberg หรือ Parquet และใช้ Email Workers เมื่ออีเมลขาเข้าคือ trigger ของระบบ ทั้งสามตัวนี้ไม่ใช่ Kafka ถ้าคุณต้องการ event log ที่ replay ย้อนหลังได้หรือ throughput ระดับหลายแสน message ต่อวินาที Cloudflare ยังไม่ใช่คำตอบ (ราคา ณ กรกฎาคม 2026)
ทีมส่วนใหญ่ที่ย้ายงาน background มาอยู่บน Cloudflare มักเริ่มจากคำถามเดียวกัน คือ "ผมมีงานที่ไม่อยากให้ user รอ ควรเอาไปไว้ตรงไหน" คำตอบบน Cloudflare Developer Platform มีสามทางหลัก และมันแก้ปัญหาคนละแบบกันจริง ๆ ไม่ใช่ของซ้ำซ้อน
บทความนี้ไม่ได้เขียนมาเพื่อเล่าว่าแต่ละตัวทำอะไรได้บ้าง เอกสารของ Cloudflare ทำหน้าที่นั้นดีอยู่แล้ว สิ่งที่เราจะทำคือบอกว่าเลือกตัวไหนในสถานการณ์ไหน ต้นทุนจริงเท่าไร และเส้นที่ทำให้คุณควรเดินออกจาก Cloudflare ไปหา Kafka หรือ SQS อยู่ตรงไหน ตัวเลขทั้งหมดมาจากหน้าเอกสารและหน้าราคาอย่างเป็นทางการของ Cloudflare ณ กรกฎาคม 2026
ก่อนอ่านต่อ มีบริบทหนึ่งที่ต้องเข้าใจก่อน คือ Workers คิดเงินตาม CPU time ไม่ใช่ wall-clock time งานที่นั่งรอ API ภายนอกตอบกลับไม่ได้ถูกคิดเงินตอนที่มันรออยู่ นี่คือเหตุผลที่ pipeline แบบ fan-out ไปเรียก API หลายตัวมักถูกกว่าที่คนคาดไว้มาก รายละเอียดเชิงเปรียบเทียบเราเขียนไว้แล้วใน Cloudflare Workers กับ AWS Lambda
Cloudflare Queues: คิวที่คิดเงินเป็น operation
Queues คือคิวข้อความแบบ push-based (และมี pull consumer ให้เลือก) ที่ผูกกับ Worker ผ่าน binding โปรดิวเซอร์เขียนข้อความเข้าคิว คอนซูมเมอร์เป็น Worker อีกตัวที่ Cloudflare เรียกให้เองเป็น batch พร้อม retry และ Dead Letter Queue ในตัว
วิธีคิดเงินที่คนพลาดบ่อยที่สุด
Queues ไม่ได้คิดเงินตามจำนวนข้อความ แต่คิดตามจำนวน operation โดยหนึ่ง operation คือทุก ๆ 64 KB ของข้อมูลที่ถูกเขียน อ่าน หรือลบ ข้อความปกติหนึ่งข้อความที่ส่งผ่านครบวงจรจะกิน 3 operation คือ write หนึ่ง read หนึ่ง delete หนึ่ง
จุดที่คนคิดพลาดคือข้อความที่ใหญ่เกิน 64 KB จะถูกคิดเป็นหลาย operation ข้อความขนาด 127 KB ถูกคิดเป็นสอง chunk ทำให้ค่าใช้จ่ายเป็นสองเท่าทันที และทุกครั้งที่ retry จะนับเป็น read เพิ่มอีกหนึ่งครั้งต่อข้อความ ไม่ใช่ต่อ batch แปลว่า batch 10 ข้อความที่ retry หนึ่งรอบ กิน 10 operation เพิ่ม ไม่ใช่หนึ่ง
| รายการ | Workers Free | Workers Paid |
|---|---|---|
| Standard operations | 10,000 operations/วัน | 1,000,000 operations/เดือน แล้ว $0.40 ต่อล้าน operation |
| Message retention | 24 ชั่วโมง (แก้ไม่ได้) | ค่าเริ่มต้น 4 วัน ตั้งได้ถึง 14 วัน |
| ขนาดข้อความสูงสุด | 128 KB | |
| Throughput ต่อคิว | 5,000 ข้อความ/วินาที | |
| Backlog ต่อคิว | 25 GB | |
| Batch สูงสุดต่อ consumer | 100 ข้อความ | |
| Concurrent consumer invocations | 250 (push-based) | |
| Consumer duration (wall clock) | 15 นาที | |
| Egress / bandwidth | ไม่คิดเงิน | |
ลิมิต 15 นาที คือเส้นแบ่งที่สำคัญที่สุด
Queue consumer มีเพดาน wall-clock time ที่ 15 นาทีต่อการเรียกหนึ่งครั้ง เท่ากับ Cron Triggers และ Durable Object alarm handlers ตัวเลขนี้ไม่ใช่ CPU time แต่คือเวลาจริงตั้งแต่เริ่มจนจบ รวมเวลาที่นั่งรอ network ด้วย
ถ้างานหนึ่งชิ้นของคุณ เช่น การ transcode หรือการเรียก API ภายนอกที่ช้ามาก ใช้เวลาเกิน 15 นาที คุณจะไม่มีทางทำมันจบใน consumer เดียวได้เลย ทางออกคือซอยงานเป็น step ย่อยแล้วส่งกลับเข้าคิวใหม่ หรือย้ายไปใช้ Workflows ซึ่งไม่มีเพดาน wall time ต่อ step
ส่วน CPU time นั้นค่าเริ่มต้นคือ 30 วินาที และปรับขึ้นได้ถึง 5 นาทีบน Workers Paid ผ่าน limits.cpu_ms ใน Wrangler config
ใช้ Queues เมื่อไหร่ / ไม่ควรใช้เมื่อไหร่
ใช้เมื่อ: คุณต้องการดันงานออกจาก request path เพื่อให้ผู้ใช้ได้ response เร็ว งานนั้นต้อง retry ได้เมื่อล้มเหลว และคุณอยากได้ Dead Letter Queue ฟรีโดยไม่ต้องเขียนเอง ตัวอย่างที่เข้าทางมาก ๆ คือ ประมวลผลออร์เดอร์หลังชำระเงิน ส่งอีเมลยืนยัน สร้าง thumbnail จากไฟล์ที่เพิ่งอัปโหลด และ webhook fan-out
ไม่ควรใช้เมื่อ: คุณต้องการ replay event เดิมย้อนหลัง เพราะ Queues ลบข้อความหลัง ack และเก็บได้สูงสุด 14 วันเท่านั้น มันคือคิว ไม่ใช่ log; คุณต้องการ throughput เกิน 5,000 ข้อความต่อวินาทีต่อคิว; คุณต้องการ consumer หลายกลุ่มอ่าน stream เดียวกันแบบอิสระ (consumer group แบบ Kafka); หรือข้อความของคุณใหญ่กว่า 128 KB ซึ่งกรณีนั้นควรเก็บ payload ไว้ใน R2 แล้วส่งเฉพาะ key เข้าคิว
Cloudflare Pipelines: ingest แล้ว SQL แล้วลง R2
Pipelines เป็นคนละสัตว์กับ Queues โดยสิ้นเชิง มันไม่ได้ออกแบบมาให้ "ทำงาน" ต่อข้อความ แต่ออกแบบมาเพื่อรับ event ปริมาณมาก แปลงด้วย SQL แล้วเขียนลง R2 เป็น Apache Iceberg table หรือไฟล์ Parquet และ JSON
โครงสร้างมีสามชิ้น คือ stream (คิวที่รับ event ผ่าน HTTP endpoint หรือ Worker binding), pipeline (SQL transformation) และ sink (ปลายทางบน R2 หรือ R2 Data Catalog) Cloudflare ระบุว่า delivery ไปยัง sink เป็นแบบ exactly-once
ราคาและลิมิตช่วง open beta
ตอนนี้ Pipelines อยู่ใน open beta ใช้ได้กับทุกบัญชีที่มี Workers Paid และ Cloudflare ยังไม่คิดเงินสำหรับตัว Pipelines เอง คุณจ่ายแค่ค่า R2 storage และ operation ตามปกติสำหรับข้อมูลที่ sink เขียนลงไป Cloudflare แจ้งว่าจะให้เวลาอย่างน้อย 30 วันก่อนเริ่มเก็บเงิน โดยจะคิดตามปริมาณข้อมูลที่ ingest แปลง และส่งลง sink
ลิมิตช่วง beta ค่อนข้างแคบ และคุณต้องดูก่อนออกแบบ ได้แก่ stream สูงสุด 20 ตัวต่อบัญชี, sink สูงสุด 20 ตัว, pipeline สูงสุด 20 ตัว, payload สูงสุด 5 MB ต่อหนึ่ง ingestion request และ ingest rate สูงสุด 5 MB/s ต่อ stream
ใช้ Pipelines เมื่อไหร่ / ไม่ควรใช้เมื่อไหร่
ใช้เมื่อ: คุณมี clickstream, server log, telemetry จาก IoT หรือ mobile event ที่อยากเก็บลง data lake แล้วเอาไป query ทีหลัง และคุณไม่อยากดูแล Kafka Connect หรือ Flink เอง จุดขายจริงคือ R2 ไม่คิด egress เลย ทำให้ข้อมูลที่กองไว้ใน lake ถูกดึงไป query จาก engine ภายนอกได้โดยไม่โดนค่าออกข้อมูล ประเด็นนี้เราแยกอธิบายไว้ใน R2 กับ S3
ไม่ควรใช้เมื่อ: คุณต้องการ latency ระดับต่ำกว่าวินาทีจาก producer ถึง consumer เพราะ Pipelines คือ batch ลง object storage ไม่ใช่ message bus; คุณต้องการ ingest เกิน 5 MB/s ต่อ stream; หรือคุณต้องการให้ระบบอื่นมา subscribe event แบบ real-time ต่อ ในกรณีหลังคุณอยากได้ Kafka หรือคิวจริง ๆ ไม่ใช่ pipeline ลง lake
และเพราะยังเป็น beta ที่ราคายังไม่ประกาศ การวาง Pipelines ไว้ใน critical path ของระบบที่คิดเงินลูกค้าอยู่ตอนนี้ ถือเป็นความเสี่ยงทางธุรกิจที่ควรพูดกับทีมให้ชัดก่อน
Email Workers: อีเมลในฐานะ trigger
สิ่งที่เคยชื่อ Email Routing ตอนนี้ถูกรวมอยู่ใต้ผลิตภัณฑ์ชื่อ Email Service ซึ่งครอบทั้งอีเมลขาเข้า (routing) และขาออก (sending) แนวคิดหลักยังเหมือนเดิม คือคุณชี้ MX ของโดเมนมาที่ Cloudflare แล้วเขียน Worker ที่มี email handler รับ message เข้ามาเป็น object ที่อ่าน header, parse MIME, forward, reject หรือส่งต่อเข้า Queue ได้
ราคาและลิมิตที่ต้องรู้
| รายการ | Free | Paid |
|---|---|---|
| อีเมลขาเข้า (Email Routing) | ไม่จำกัด | ไม่จำกัด |
| อีเมลขาออก (Email Sending) | ส่งได้เฉพาะปลายทางที่ verify แล้วในบัญชี | $0.35 ต่อ 1,000 ฉบับ |
| ขนาดข้อความสูงสุด | 25 MiB รวม attachment | |
| ผู้รับต่อฉบับ (to + cc + bcc) | 50 | |
| Rules / destination addresses | 200 / 200 | |
| ตัว Worker เอง | คิดเงินตามราคา Workers ปกติ | |
ข้อควรระวังคือ Worker ที่ประมวลผลอีเมลก็ยังอยู่ใต้ลิมิต Workers ทั่วไป memory 128 MB ต่อ isolate ซึ่งปรับขึ้นไม่ได้ทั้งบน Free และ Paid การพยายาม parse อีเมลขนาด 20 MB ที่มี attachment หนัก ๆ ใน Worker เดียวจึงเสี่ยงชน memory limit ทางที่ปลอดภัยกว่าคือเขียน raw message ลง R2 ก่อน แล้วส่ง key เข้า Queue ให้ consumer ค่อยไปทำงานหนักต่อ
ใช้ Email Workers เมื่อไหร่ / ไม่ควรใช้เมื่อไหร่
ใช้เมื่อ: อีเมลขาเข้าเป็น trigger ของ business logic เช่น ระบบ support ที่เปิด ticket จากอีเมล ระบบรับใบสั่งซื้อจาก supplier ที่ยังส่งเป็นอีเมล ระบบ parse bounce notification หรือระบบกรอง spam ด้วยตรรกะของคุณเอง และคุณต้องการส่งอีเมล transactional จำนวนไม่มากออกไปด้วย เช่น magic link หรืออีเมลยืนยัน
ไม่ควรใช้เมื่อ: คุณกำลังทำ marketing email หรือ newsletter ที่ต้องการ template editor, segmentation, A/B test, การจัดการ unsubscribe แบบครบวงจร และรายงาน deliverability เชิงลึก เครื่องมืออย่าง SendGrid, Postmark หรือ Amazon SES ยังทำงานนั้นได้ดีกว่าชัดเจน Email Service ของ Cloudflare วางตัวเป็น primitive สำหรับ developer ไม่ใช่ ESP เต็มรูปแบบ
Workflows: เมื่อ 15 นาทีไม่พอ
ถ้างานของคุณเป็นลำดับขั้นที่ยาว มี state ต้องจำ และมีขั้นที่ต้องรอเป็นชั่วโมงหรือเป็นวัน Queues ไม่ใช่คำตอบ Workflows คือคำตอบ เพราะแต่ละ step ไม่มีเพดาน wall time (แต่ยังอยู่ใต้เพดาน CPU time ที่ตั้งไว้) และ step ที่นั่ง sleep อยู่ไม่กิน CPU time เลย
ปัจจุบัน Workflows คิดเงินเหมือน Workers ทุกประการ คือ requests, CPU time และ storage โดย Workers Paid ให้ 10 ล้าน request และ 30 ล้าน CPU-millisecond ต่อเดือน กับ storage 1 GB แล้วคิดเพิ่ม $0.20 ต่อ GB-เดือน
สิ่งที่กำลังจะเปลี่ยน: ตาม changelog วันที่ 7 กรกฎาคม 2026 Cloudflare ประกาศว่า Workflows จะย้ายไปคิดเงินแบบต่อ step โดยจะเริ่มไม่เร็วกว่าวันที่ 10 สิงหาคม 2026 แผน Paid จะรวม 500,000 step ต่อเดือน แล้วคิดเพิ่ม $0.80 ต่อ 100,000 step ส่วนแผน Free ให้ 3,000 step ต่อวัน ถ้าคุณกำลังออกแบบ workflow ที่มี step ย่อยจำนวนมาก ตัวเลขนี้ควรอยู่ในโมเดลต้นทุนของคุณตั้งแต่วันนี้ ไม่ใช่ไปเจอเอาตอนบิลมา
ตัวอย่างที่หนึ่ง: คิวประมวลผลออร์เดอร์ 2 ล้านข้อความต่อเดือน
สมมติร้านค้าออนไลน์แห่งหนึ่งในไทยมีออร์เดอร์ที่ต้องประมวลผลหลังชำระเงิน 2 ล้านรายการต่อเดือน แต่ละ message เล็กกว่า 64 KB (เก็บแค่ order id กับ metadata) consumer ทำงานเป็น batch ละ 10
| รายการ | การคำนวณ | ค่าใช้จ่าย/เดือน |
|---|---|---|
| Workers Paid | ค่าธรรมเนียมพื้นฐาน | $5.00 |
| Queues operations | 2,000,000 x 3 = 6,000,000 ops ลบส่วนที่รวมให้ 1,000,000 เหลือ 5,000,000 x $0.40/ล้าน | $2.00 |
| Retry 5% (อ่านซ้ำ 1 รอบ) | 100,000 read ops x $0.40/ล้าน | $0.04 |
| Worker requests | 2,000,000 / 10 = 200,000 invocations (รวมอยู่ใน 10 ล้าน) | $0.00 |
| CPU time | สมมติ 50 ms CPU ต่อ invocation = 10 ล้าน CPU-ms (รวมอยู่ใน 30 ล้าน) | $0.00 |
| รวม | ประมาณ $7.04 |
ตัวเลขที่น่าสนใจคือ ค่าคิวเองอยู่ที่ 2 ดอลลาร์ ส่วนที่เหลือคือค่าธรรมเนียมพื้นฐานของแพลตฟอร์มที่คุณจ่ายอยู่แล้ว การเพิ่มปริมาณเป็นสองเท่าจะเพิ่มค่าใช้จ่ายราว 2.4 ดอลลาร์ ไม่ใช่เท่าตัว เพราะ 5 ดอลลาร์แรกเป็นค่าคงที่ ในทางกลับกัน ถ้าข้อความของคุณโตขึ้นเป็น 100 KB ต่อชิ้น ค่า operation จะกลายเป็นสองเท่าทันที นี่คือเหตุผลที่ควรเก็บ payload ใหญ่ไว้ใน R2 แล้วส่งแค่ key
ตัวอย่างที่สอง: ระบบคัดแยก support ticket จากอีเมล
สมมติบริษัท SaaS ไทยแห่งหนึ่งรับอีเมล support เดือนละ 30,000 ฉบับ ต้องการ parse, จัดหมวดหมู่, สร้าง ticket และตอบกลับอัตโนมัติว่าได้รับเรื่องแล้ว
อีเมลขาเข้าไม่มีค่าใช้จ่ายเลย เพราะ Email Routing ไม่จำกัดจำนวนทั้งบน Free และ Paid ตัว Email Worker ที่รับ 30,000 invocation ต่อเดือนอยู่ในโควตา 10 ล้าน request ที่รวมอยู่ใน Workers Paid แล้ว ส่วนที่มีค่าใช้จ่ายจริงคืออีเมลตอบกลับ 30,000 ฉบับ ที่ $0.35 ต่อ 1,000 ฉบับ เท่ากับ $10.50 ต่อเดือน
รวมทั้งระบบจึงอยู่ที่ประมาณ $15.50 ต่อเดือน (Workers Paid $5.00 บวกค่าส่งอีเมล $10.50) ก่อนบวกค่า AI ถ้าคุณจะเอา Workers AI มาช่วยจัดหมวดหมู่ ซึ่งเป็นเรื่องที่เราแยกคุยไว้ต่างหาก
ข้อควรระวังในทางปฏิบัติ: อีเมลที่มี attachment ใหญ่จะกิน memory ของ Worker เร็วมาก ทางที่เราแนะนำเสมอคือให้ email handler ทำงานให้น้อยที่สุด เขียน raw message ลง R2 แล้วส่ง object key เข้า Queue จากนั้นให้ consumer ที่มี CPU limit สูงกว่าเป็นคนแกะ MIME และเรียกโมเดล
ตารางตัดสินใจ: ถ้าคุณต้องการ X ให้ใช้ Y
| ถ้าคุณต้องการ | ให้ใช้ | เหตุผล |
|---|---|---|
| ดันงานออกจาก request path พร้อม retry อัตโนมัติ | Queues | มี retry, DLQ, batching ในตัว จ่ายตาม operation |
| งานที่ใช้เวลาเกิน 15 นาที หรือมีขั้นที่ต้องรอเป็นวัน | Workflows | ไม่มีเพดาน wall time ต่อ step และ step ที่ sleep ไม่กิน CPU |
| เก็บ event หลายล้านชิ้นลง data lake เพื่อ query ทีหลัง | Pipelines + R2 | SQL transform ในตัว เขียนเป็น Iceberg/Parquet, egress ฟรี |
| ให้อีเมลขาเข้าเป็น trigger ของ business logic | Email Workers | อีเมลขาเข้าไม่จำกัดและไม่คิดเงิน |
| ส่งอีเมล transactional ปริมาณกลาง ๆ | Email Sending | $0.35 ต่อ 1,000 ฉบับ ไม่ต้องต่อ SMTP เอง |
| งานตามเวลา (nightly job, rollup) | Cron Triggers | เพดาน 15 นาทีเท่ากับ queue consumer |
| coordination แบบมี state ต่อ key เช่น lock หรือ counter | Durable Objects | instance เดียวต่อ key เป็นเจ้าของ state จริง |
| replay event stream ย้อนหลัง หรือ consumer group หลายกลุ่ม | Kafka (ไม่ใช่ Cloudflare) | Queues ลบข้อความหลัง ack เก็บสูงสุด 14 วัน |
| throughput เกิน 5,000 msg/s ต่อคิว | Kafka หรือ Kinesis | ชนเพดาน per-queue throughput ของ Queues |
เมื่อไหร่ที่ Kafka, SQS หรือเครื่องมืออื่นชนะ
นี่คือส่วนที่บทความส่วนใหญ่ไม่ยอมเขียน แต่ถ้าไม่เขียน คุณจะเอาไปตัดสินใจจริงไม่ได้
Kafka ชนะเมื่อคุณต้องการ log ไม่ใช่คิว
ความแตกต่างเชิงโครงสร้างคือ Kafka เก็บ event เป็น append-only log ที่ consumer แต่ละกลุ่มถือ offset ของตัวเอง อ่านซ้ำได้ ย้อนกลับได้ และเพิ่ม consumer ใหม่มาอ่านประวัติทั้งหมดตั้งแต่ต้นได้ Cloudflare Queues ไม่ใช่แบบนั้น ข้อความถูกลบเมื่อ ack และ retention สูงสุดคือ 14 วัน ถ้าสถาปัตยกรรมของคุณพึ่ง event sourcing หรือ CQRS ที่ต้อง rebuild state จาก log Cloudflare Queues ตอบโจทย์ไม่ได้
ปริมาณสูงมาก ๆ
เพดาน 5,000 ข้อความต่อวินาทีต่อคิวฟังดูเยอะ แต่ถ้าคุณกำลังทำ ad tech, ระบบ trading หรือ telemetry ระดับ fleet ที่ยิงหลักแสน event ต่อวินาที คุณจะชนเพดานนี้ และการซอยเป็นหลายคิวเพื่อเลี่ยงลิมิตคือการสร้าง sharding logic ขึ้นมาเองซึ่งเป็นหนี้ทางเทคนิคที่ไม่คุ้ม
SQS ชนะเมื่อระบบที่เหลือของคุณอยู่บน AWS
ถ้า workload อื่นของคุณอยู่บน AWS ทั้งหมด และคิวต้องคุยกับ Lambda, Step Functions, EventBridge และ IAM policy ที่มีอยู่แล้ว การลาก Cloudflare Queues เข้ามาแปลว่าคุณกำลังเพิ่ม cross-cloud hop และค่า egress จาก AWS ในทุก message ที่ข้ามฝั่ง ค่าใช้จ่ายและ latency ที่เพิ่มมามักกลืนข้อได้เปรียบด้านราคาจนหมด
Data lake ที่โตแล้ว
Pipelines ยังอยู่ใน open beta ลิมิตแคบ (20 stream ต่อบัญชี, 5 MB/s ต่อ stream) และราคายังไม่ประกาศ ถ้าคุณมี Flink, Spark Streaming หรือ dbt pipeline ที่ทำงานอยู่แล้วและทีมรู้จักมันดี การย้ายมา Pipelines ตอนนี้คือการแลกความสามารถและความแน่นอนด้านราคากับความสะดวก ซึ่งอาจจะยังไม่คุ้ม เราแนะนำให้เริ่มจาก use case ใหม่ที่ไม่ critical ก่อน
ประเด็นเรื่องขีดจำกัดของ runtime โดยรวม เราเขียนไว้ละเอียดกว่านี้ใน เมื่อไหร่ที่ไม่ควรใช้ Cloudflare Workers และภาพรวมของบริการ storage ทั้งชุดอยู่ใน บริการ Storage ของ Cloudflare
สรุปสำหรับคนที่ต้องตัดสินใจ
สามคำถามที่ตอบได้เร็วที่สุด: หนึ่ง งานของคุณจบใน 15 นาทีไหม ถ้าไม่ ใช้ Workflows ไม่ใช่ Queues สอง คุณต้อง replay event ย้อนหลังไหม ถ้าใช่ คุณต้องการ Kafka ไม่ใช่ Queues สาม ข้อความของคุณใหญ่กว่า 64 KB ไหม ถ้าใช่ เก็บลง R2 แล้วส่งแค่ key เพราะไม่งั้นค่า operation จะทวีคูณ
Cipher ออกแบบและพัฒนาระบบบน Cloudflare Developer Platform ให้กับธุรกิจในประเทศไทย ถ้าคุณกำลังชั่งใจระหว่าง Queues, Workflows หรือ message broker เดิมที่มีอยู่ เรารับประเมินสถาปัตยกรรมและช่วยคำนวณต้นทุนจริงจากปริมาณงานของคุณเองได้
คำถามที่พบบ่อย
Cloudflare Queues ต่างจาก Kafka อย่างไร
Queues เป็นคิว ไม่ใช่ log ข้อความจะถูกลบเมื่อ consumer ทำ ack สำเร็จ และเก็บได้สูงสุด 14 วันบน Workers Paid ส่วน Kafka เก็บ event เป็น append-only log ที่ consumer หลายกลุ่มอ่านซ้ำและย้อนกลับได้ ถ้าคุณต้องการ event sourcing หรือ replay ย้อนหลัง Queues ตอบโจทย์ไม่ได้
Queue consumer ทำงานได้นานสุดกี่นาที
15 นาทีต่อการเรียกหนึ่งครั้ง วัดเป็น wall-clock time ซึ่งเป็นเพดานเดียวกับ Cron Triggers และ Durable Object alarm handlers ส่วน CPU time ตั้งต้นที่ 30 วินาที และปรับขึ้นได้ถึง 5 นาทีบน Workers Paid ผ่าน limits.cpu_ms
Pipelines คิดเงินอย่างไรในตอนนี้
ช่วง open beta Cloudflare ยังไม่คิดเงินสำหรับตัว Pipelines เอง คุณจ่ายเฉพาะค่า R2 storage และ operation ตามปกติสำหรับข้อมูลที่ sink เขียนลง R2 Cloudflare ระบุว่าจะแจ้งล่วงหน้าอย่างน้อย 30 วันก่อนเริ่มเก็บเงิน (ข้อมูล ณ กรกฎาคม 2026)
Email Workers ส่งอีเมลออกได้ไหม และราคาเท่าไร
ได้ ผ่าน send_email binding ของ Email Service อีเมลขาเข้าไม่จำกัดและไม่คิดเงินทั้งบน Free และ Paid ส่วนอีเมลขาออกบนแผน Paid คิดที่ $0.35 ต่อ 1,000 ฉบับ โดยแผน Free ส่งได้เฉพาะปลายทางที่ verify แล้วในบัญชี
ถ้างานใช้เวลานานกว่า 15 นาที ควรใช้อะไร
ใช้ Workflows เพราะแต่ละ step ไม่มีเพดาน wall time และ step ที่ sleep อยู่ไม่กิน CPU time ควรทราบด้วยว่า Cloudflare ประกาศ (changelog 7 กรกฎาคม 2026) ว่าจะย้าย Workflows ไปคิดเงินแบบต่อ step โดยเริ่มไม่เร็วกว่า 10 สิงหาคม 2026 แผน Paid จะรวม 500,000 step ต่อเดือน แล้วคิดเพิ่ม $0.80 ต่อ 100,000 step
