Azure Container Apps Event Driven Design — คู่มือฉบับสมบูรณ์ 2026 | SiamCafe Blog

Azure Container Apps Event Driven Design คืออะไร — ทำความเข้าใจจากรากฐาน

ในโลกของไอทีปัจจุบันที่ระบบต้องรองรับผู้ใช้จำนวนมหาศาลและต้องตอบสนองแบบเรียลไทม์ การออกแบบระบบแบบ Event Driven บน Azure Container Apps

ได้กลายเป็นทักษะที่ทีม DevOps Engineer และ System Administrator ต้องมีติดตัว หลักการของ Event Driven Design ง่าย ๆ คือ แทนที่จะให้แต่ละส่วนของระบบเรียกหากันโดยตรงแบบรอคอยผลลัพธ์ เราจะให้ทุกส่วนส่ง "เหตุการณ์" (Event) ออกไป แล้วให้ส่วนที่สนใจเหตุการณ์นั้นค่อย ๆ รับและประมวลผลในเวลาของตัวเอง

Azure Container Apps เป็นแพลตฟอร์มแบบ Serverless Container บน Microsoft Azure ที่รองรับการขยายตัวตามเหตุการณ์ (Event-driven Scaling) โดยตรง จุดเด่นที่ผมชอบที่สุดคือรองรับ KEDA (Kubernetes Event-driven Autoscaling) ในตัว ทำให้แอปพลิเคชันของเราสามารถขยายจำนวน Replicas ตามความยาวคิวของข้อความ หรือจำนวนเหตุการณ์ที่รอประมวลผล และที่สำคัญคือสามารถ Scale ลงไปเหลือศูนย์ได้ ซึ่งช่วยประหยัดค่าใช้จ่ายอย่างมหาศาลเมื่อระบบไม่มีงาน

ผมเริ่มทำงานด้านไอทีมายาวนาน ผ่านทั้งยุคเครื่องกายภาล้วน ยุค Virtualization ยุคคลาวด์ จนถึงยุค Container Orchestration ปัจจุบัน และในขณะเดียวกันผมก็เทรดฟอเร็กซ์กับ XM มากว่าสิบสามปี จึงมีมุมมองว่าระบบที่ดีต้องเสถียรเหมือนการจัดการความเสี่ยงในการเทรด นั่นคือต้องแยกส่วน ต้องมีเบ็ดความเสียหายที่จำกัด และต้องไม่พึ่งพาส่วนเดียวมากเกินไป Event Driven Design ตอบโจทย์นี้ได้ดีมาก เพราะการแยกความสัมพันธ์ระหว่างบริการ (Decoupling) ช่วยให้บางส่วนล่มได้โดยไม่โดมโดยรวมทั้งระบบ

สำหรับใครที่กำลังจะเริ่ม ผมแนะนำให้เข้าใจสามแนวคิดหลักก่อนคือ Producer (ผู้ส่งเหตุการณ์) Consumer (ผู้รับประมวลผล) และ Message Broker (ตัวกลางส่งต่อ) บน Azure ที่นิยมคือ Azure Service Bus, Azure Event Hubs และ Azure Storage Queue ซึ่งทั้งหมดเชื่อมกับ Container Apps ได้โดยตรงผ่าน KEDA Scaler

เมื่อจะออกแบบระบบแบบ Event Driven บน Azure Container Apps สิ่งแรกที่ต้องตัดสินใจคือเลือกตัวกลางสำหรับส่งเหตุการณ์ให้เหมาะกับลักษณะงาน

จากประสบการณ์ที่ผมช่วยลูกค้าหลายโครงการ การเลือกผิดตั้งแต่ต้นทำให้ต้องรื้อระบบกลางทางเสมอ จึงขอสรุปตารางเปรียบเทียบให้ดูก่อน

เมื่อจะออกแบบระบบแบบ Event Driven บน Azure Container Apps สิ่งแรกที่ต้องตัดสินใจคือเลือกตัวกลางสำหรับส่งเหตุการณ์ให้เหมาะกับลักษณะงาน จากประสบการณ์ที่ผมช่วยลูกค้าหลายโครงการ การเลือกผิดตั้งแต่ต้นทำให้ต้องรื้อระบบกลางทางเสมอ จึงขอสรุปตารางเปรียบเทียบให้ดูก่อน

บริการ Azure	เหมาะกับงานแบบไหน	ลำดับการส่ง	ขนาดข้อความ	ราคาโดยประมาณ
Azure Storage Queue	งานง่าย ๆ คิวต่อคิว ปริมาณสูง	ไม่รับประกัน	สูงสุด 64 กิโลไบต์	ถูกที่สุด
Azure Service Bus Queue	งานธุรกิจที่ต้องการรับประกันการส่ง	รับประกันแบบ FIFO	สูงสุด 1 เมกะไบต์	ปานกลาง
Azure Event Hubs	สตรีมข้อมูลปริมาณมหาศาล บันทึกเหตุการณ์	ตามพาร์ติชัน	สูงสุด 1 เมกะไบต์	ตาม Throughput
Azure Event Grid	การตอบสนองเหตุการณ์จากบริการ Azure	ไม่รับประกัน	เล็ก (ทำงานเป็นตัวแจ้ง)	จ่ายตามจำนวนเหตุการณ์

จากตารางข้างต้น หลักการเลือกของผมคือถ้าเป็นคำสั่งธุรกิจที่ห้ามหาย เช่น การสร้างใบสั่งซื้อ ให้ใช้ Service Bus ที่มีระบบ Dead Letter Queue รองรับ แต่ถ้าเป็นสตรีมบันทึกพฤติกรรมผู้ใช้ปริมาณมหาศาล ให้ใช้ Event Hubs เพราะรับสตรีมได้เป็นล้านเหตุการณ์ต่อวินาที ส่วน Event Grid เหมาะกับการเชื่อมเหตุการณ์ระหว่างบริการ Azure เข้าด้วยกัน เช่น เมื่อไฟล์ขึ้นไปที่ Blob Storage แล้วให้เรียก Container App มาประมวลผลทันที

อีกส่วนสำคัญคือ KEDA ที่ทำงานในเบื้องหลังของ Container Apps โดยอัตโนมัติ เราเพียงกำหนด Scale Rule ในไฟล์ Template ของ Container App เช่น ระบุว่าให้ขยายตามความยาวคิวของ Service Bus โดยทุก ๆ สิบข้อความให้เพิ่มหนึ่ง Replicas และกำหนดขั้นต่ำเป็นศูนย์กับขั้นสูงสุดเป็นสิบ ระบบจะจัดการเองทั้งหมดโดยไม่ต้องเขียนโค้ดขยายตัวเองเลย

สิ่งที่มือใหม่มักมองข้ามคือเรื่อง Idempotency หรือความสามารถในการประมวลผลข้อความเดิมซ้ำโดยไม่เกิดผลข้างเคียง เพราะระบบคิวทุกตัวมีโอกาสส่งข้อความซ้ำ (At-least-once delivery) การออกแบบที่ดีต้องให้ทุกเหตุการณ์มีรหัสเฉพาะ แล้วเก็บรหัสที่ประมวลผลแล้วไว้ตรวจสอบก่อนทำงาน ผมเคยเจอระบบที่ตัดเงินซ้ำเพราะไม่จัดการตรงนี้ เสียหายทั้งค่าใช้จ่ายและความเชื่อมั่นจากลูกค้า

ขั้นตอนติดตั้งและตั้งค่า Event Driven App บน Azure Container Apps

เริ่มต้นด้วยการเตรียมเครื่องมือ ผมแนะนำให้ติดตั้ง Azure CLI บนเครื่องทำงานและเข้าสู่ระบบด้วยคำสั่งข้างล่างนี้

curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash az login az account set --subscription "ชื่อ-Subscription-ของคุณ"

az provider register --namespace Microsoft.App az provider register --namespace Microsoft.OperationalInsights

จากนั้นสร้าง Resource Group และสภาพแวดล้อม Container Apps ซึ่งเป็นพื้นที่ทำงานที่แอปของเราจะอยู่

az group create --name rg-eventdriven --location southeastasia az containerapp env create \ --name env-ca-prod \ --resource-group rg-eventdriven \ --location southeastasia

เมื่อมีสภาพแวดล้อมแล้ว ให้สร้าง Service Bus และคิวที่จะใช้เป็นตัวกลางส่งเหตุการณ์

az servicebus namespace create \ --resource-group rg-eventdriven \ --name sb-siamcafe-prod \ --sku Standard

az servicebus queue create \ --resource-group rg-eventdriven \ --namespace-name sb-siamcafe-prod \ --name order-events \ --max-size 1024 \ --dead-lettering-on-message-expiration true

ขั้นถัดไปคือ Deploy Container App ที่รับฟังคิว พร้อมกำหนด Scale Rule ให้ขยายตามคิวโดยอัตโนมัติ ในที่นี้ผมใช้ภาพคอนเทนเนอร์ตัวอย่างเพื่อสาธิต

az containerapp create \ --name worker-order-processor \ --resource-group rg-eventdriven \ --environment env-ca-prod \ --image mcr.microsoft.com/azuredocs/containerapps-helloworld:latest \ --secrets servicebus-connection="Connection-String-ของคุณ" \ --scale-rule name sb-queue-rule \ --scale-rule-type azure-servicebus \ --scale-rule-metadata queueName=order-events \ namespace=sb-siamcafe-prod \ messageCount=10 \ --min-replicas 0 \ --max-replicas 10

จุดที่ต้องสังเกตคือ `--min-replicas 0` ซึ่งหมายความว่าเมื่อคิวว่างระบบจะยุบ Replicas ไปเหลือศูนย์ ประหยัดค่าใช้จ่ายเต็ม ๆ และเมื่อมีคนส่งข้อความเข้าคิว KEDA จะปลุกแอปขึ้นมาทำงานภายในไม่กี่วินาที จากประสบการณ์ผมมาตรวจสอบสถานะ Scaling ด้วยคำสั่ง

az containerapp revision list \ --name worker-order-processor \ --resource-group rg-eventdriven \ -o table

az monitor metrics list \ --resource $(az containerapp show --name worker-order-processor \ --resource-group rg-eventdriven --query id -o tsv) \ --metric "Replicas" --interval PT1M

เรื่องที่หลายทีมเจอปัญหาที่สุดในระบบแบบเหตุการณ์คือการจัดการข้อผิดพลาด เพราะเมื่อข้อความประมวลผลไม่สำเร็จ มันจะกลับเข้าคิวและถูกพยายามใหม่ไปเรื่อย ๆ

จนกระทบคิวทั้งคิว ผมจึงยึดหลักสามข้อเสมอ ข้อแรกคือกำหนดจำนวนครั้งที่พยายามใหม่ให้ชัดเจน เช่น ห้าครั้ง พร้อม Delay แบบเพิ่มขึ้นเรื่อย ๆ (Exponential Backoff) ข้อสองคือทุกข้อความที่พยายามครบแล้วต้องถูกส่งไป Dead Letter Queue เพื่อให้ทีมตรวจสอบภายหลัง ไม่ปล่อยหายเด็ดขาด ข้อสามคือเขียนบันทึกเหตุการณ์ที่ประมวลผลล้มเหลวพร้อมรหัสเฉพาะ ตัวอย่างการกำหนดค่าใน Service Bus

ความปลอดภัยและการจัดการข้อผิดพลาดในระบบ Event Driven

เรื่องที่หลายทีมเจอปัญหาที่สุดในระบบแบบเหตุการณ์คือการจัดการข้อผิดพลาด เพราะเมื่อข้อความประมวลผลไม่สำเร็จ มันจะกลับเข้าคิวและถูกพยายามใหม่ไปเรื่อย ๆ จนกระทบคิวทั้งคิว ผมจึงยึดหลักสามข้อเสมอ ข้อแรกคือกำหนดจำนวนครั้งที่พยายามใหม่ให้ชัดเจน เช่น ห้าครั้ง พร้อม Delay แบบเพิ่มขึ้นเรื่อย ๆ (Exponential Backoff) ข้อสองคือทุกข้อความที่พยายามครบแล้วต้องถูกส่งไป Dead Letter Queue เพื่อให้ทีมตรวจสอบภายหลัง ไม่ปล่อยหายเด็ดขาด ข้อสามคือเขียนบันทึกเหตุการณ์ที่ประมวลผลล้มเหลวพร้อมรหัสเฉพาะ ตัวอย่างการกำหนดค่าใน Service Bus

az servicebus queue update \ --resource-group rg-eventdriven \ --namespace-name sb-siamcafe-prod \ --name order-events \ --max-delivery-count 5 \ --lock-duration PT2M

ด้านความปลอดภัย ผมไม่แนะนำให้ฝัง Connection String ไว้ในโค้ดหรือภาพคอนเทนเนอร์เด็ดขาด แนะนำให้ใช้ Managed Identity ของ Azure แทน โดยเปิดให้ Container App มีตัวตนของตัวเองแล้วมอบสิทธิ์เข้าถึง Service Bus เฉพาะจุด

az containerapp identity assign \ --name worker-order-processor \ --resource-group rg-eventdriven \ --system-assigned

PRINCIPAL_ID=$(az containerapp show \ --name worker-order-processor \ --resource-group rg-eventdriven \ --query identity.principalId -o tsv)

az role assignment create \ --assignee $PRINCIPAL_ID \ --role "Azure Service Bus Data Receiver" \ --scope $(az servicebus namespace show \ --name sb-siamcafe-prod \ --resource-group rg-eventdriven --query id -o tsv)

ระบบแบบเหตุการณ์ที่ไม่มีการติดตามผลเท่ากับการเทรดโดยไม่ดูกราฟ อาจกำไรวันนี้แต่พรุ่งนี้หายนะโดยไม่รู้ตัว Azure Container Apps มีการเชื่อมกับ Azure

Monitor และ Log Analytics มาในตัว เราจึงเห็นเมตริกสำคัญได้ทันที เมตริกที่ผมดูประจำมีห้าตัวคือ จำนวน Replicas ที่กำลังทำงาน ความยาวคิวของข้อความที่รอ เวลาเฉลี่ยที่ข้อความรอในคิว จำนวนข้อความที่ตกไป Dead Letter และอัตราความสำเร็จในการประมวลผลต่อนาที ตัวอย่างการสร้างการแจ้งเตือนเมื่อคิวยาวเกินไป

อีกจุดที่ผมให้ความสำคัญเทียบเท่ากับการวางเบ็ดขาดทุนในการเทรดคือการกำหนดขีดจำกัดทรัพยากรของแต่ละ Container App เช่น จำกัดหน่วยความจำสูงสุดสองกิกะไบต์และหน่วยประมวลผลหนึ่งคอร์ ไม่ให้งานหนึ่งชิ้นกินทรัพยากรจนกระทบงานอื่นในสภาพแวดล้อมเดียวกัน นี่คือวินัยพื้นฐานที่ช่วยให้ระบบอยู่รอดในระยะยาว

การติดตามผลและการปรับประสิทธิภาพระบบ Event Driven

ระบบแบบเหตุการณ์ที่ไม่มีการติดตามผลเท่ากับการเทรดโดยไม่ดูกราฟ อาจกำไรวันนี้แต่พรุ่งนี้หายนะโดยไม่รู้ตัว Azure Container Apps มีการเชื่อมกับ Azure Monitor และ Log Analytics มาในตัว เราจึงเห็นเมตริกสำคัญได้ทันที เมตริกที่ผมดูประจำมีห้าตัวคือ จำนวน Replicas ที่กำลังทำงาน ความยาวคิวของข้อความที่รอ เวลาเฉลี่ยที่ข้อความรอในคิว จำนวนข้อความที่ตกไป Dead Letter และอัตราความสำเร็จในการประมวลผลต่อนาที ตัวอย่างการสร้างการแจ้งเตือนเมื่อคิวยาวเกินไป

az monitor metrics alert create \ --name "queue-depth-high" \ --resource-group rg-eventdriven \ --scopes $(az servicebus namespace show \ --name sb-siamcafe-prod \ --resource-group rg-eventdriven --query id -o tsv) \ --condition "total metricName='MessagesInQueue' > 1000" \ --window-size 5m \ --evaluation-frequency 1m \ --action action-group-ops-team \ --severity 2

นอกจากนี้ยังสามารถเปิดใช้ Application Insights ใน Container App เพื่อติดตาม Distributed Tracing ข้ามบริการได้ ซึ่งสำคัญมากในสถาปัตยกรรมแบบเหตุการณ์ เพราะข้อความหนึ่งอาจเดินทางผ่านหลายบริการกว่าจะเสร็จ ถ้าไม่มีรหัสติดตามร่วมกัน (Correlation ID) จะหาต้นตอปัญหาแทบไม่ได้ ผมจึงกำหนดให้ทุกเหตุการณ์แนบรหัสติดตามไว้ในส่วนหัวของข้อความเสมอ

ด้านการปรับประสิทธิภาพ สิ่งที่เห็นผลทันทีคือการปรับค่า Message Count ใน Scale Rule เช่นถ้างานแต่ละชิ้นใช้เวลานาน การให้หนึ่ง Replicas รับผิดชอบห้าข้อความจะดีกว่าสิบข้อความ เพราะไม่ให้คิวยาวเกินตัว ในทางกลับกันถ้างานเบาและเร็ว การเพิ่มค่านี้ช่วยลดจำนวน Replicas และลดค่าใช้จ่าย อีกเทคนิคคือการแบ่งคิวตามลำดับความสำคัญ งานเร่งด่วนอย่างการยืนยันชำระเงินใช้คิวแยกที่มี Resource จองไว้ ส่วนงานปกติอย่างการส่งอีเมลยืนยันใช้คิวที่ Scale เหลือศูนย์ได้

เมื่อผมประเมินระบบใหม่ทุกครั้งจะถามตัวเองสามข้อคือ ถ้าคิวล้มจะเกิดอะไรขึ้น ถ้า Consumer ล่มกลางทางข้อความจะหายไหม และถ้าปริมาณโตขึ้นสิบเท่าในชั่วข้ามคืนระบบจะรับไหม ถ้าตอบได้ครบทั้งสามข้อ ระบบก็พร้อมขึ้นจริง

ตัวอย่างจริงและแนวทางปฏิบัติจากประสบการณ์ตรง

ขอเล่ากรณีศึกษาจริงจากโครงการที่ผมช่วยวางระบบให้ร้านค้าออนไลน์สายหนึ่งที่รับออร์เดอร์ประมาณสามหมื่นรายการต่อวันและพุ่มถึงแสนรายการในช่วงโปรโมชันเดือนเก้าของปี 2025 เดิมระบบเป็นแบบ Monolith ที่ทำทุกอย่างในกระบวนการเดียว เวลาขายดีเว็บค้าง ลูกค้าจ่ายเงินแล้วระบบไม่บันทึก ปัญหาทบทวนทุกรอบการโปรโมชัน

แนวทางที่เราวางคือแยกกระบวนการหลักออกเป็นเหตุการณ์ เมื่อลูกค้ากดสั่งซื้อ หน้าเว็บเพียงส่งเหตุการณ์ว่ามีออร์เดอร์เกิดขึ้นเข้า Service Bus แล้วตอบกลับลูกค้าทันทีว่าได้รับคำสั่งแล้ว จากนั้นมี Worker สามตัวแยกกันบน Container Apps คือตัวตรวจสอบการชำระเงิน ตัวอัปเดตสต๊อกสินค้า และตัวส่งอีเมลยืนยัน แต่ละตัวขยายตัวอิสระตามคิวของตัวเองผ่าน KEDA ผลลัพธ์คือเวลาตอบสนองของหน้าเว็บลดจากแปดวินาทีเหลือไม่ถึงหนึ่งวินาที และที่สำคัญเมื่อระบบสต๊อกล่มช่วงหนึ่ง ออร์เดอร์ยังรับได้ปกติเพราะข้อความรออยู่ในคิวแล้วประมวลผลใหม่เมื่อระบบกลับมา ไม่มีออร์เดอร์หายแม้แต่รายการเดียว

ค่าใช้จ่ายก็ลดลงเพราะ Worker ส่งอีเมลซึ่งทำงานเฉพาะเวลากลางวันถูกยุบเหลือศูนย์ Replicas ในตอนกลางคืน เทียบกับการจ่ายค่าเครื่องเดิมตลอดยี่สิบสี่ชั่วโมง

จากประสบการณ์นี้ผมสรุปแนวปฏิบัติที่ใช้ตรวจสอบก่อนขึ้นจริงหกข้อคือ หนึ่ง ทุก Consumer ต้องไม่มีสถานะ (Stateless) เพื่อขยายตัวได้อิสระ สอง ทุกการประมวลผลต้อง Idempotent กันข้อความซ้ำ สาม กำหนด Dead Letter Queue และมีคนดูแลทุกวัน สี่ แนบ Correlation ID ทุกเหตุการณ์เพื่อติดตามข้ามบริการ ห้า ทดสอบสถานการณ์ล่มด้วยการปิด Consumer กลางการประมวลผลแล้วยืนยันว่าข้อความกลับคิวถูกต้อง และหก ตั้งการแจ้งเตือนความยาวคิวและ Dead Letter ตั้งแต่วันแรก ไม่ใช่ไปเปิดทีหลังตอนเกิดปัญหาแล้ว

สำหรับท่านที่อยากฝึกก่อนขึ้นจริง แนะนำสร้างสภาพแวดล้อมทดสอบแยก Resource Group ลบทิ้งได้ง่ายเมื่อเลิกใช้ เพราะค่าใช้จ่าย Container Apps ต่อวันในระดับทดลองไม่กี่บาทเท่านั้น คุ้มค่ากับประสบการณ์ที่ได้มากกว่าอ่านจากหนังสือสิบเล่ม

คำถามที่พบบ่อย

Azure Container Apps Event Driven Design คืออะไร และแตกต่างจากการออกแบบระบบแบบเดิมอย่างไร?

Azure Container Apps Event Driven Design คือแนวทางการออกแบบระบบที่แทนที่แต่ละส่วนของระบบจะเรียกหากันโดยตรงแบบรอคอยผลลัพธ์ ทุกส่วนจะส่ง "เหตุการณ์" (Event) ออกไป แล้วให้ส่วนที่สนใจเหตุการณ์นั้นค่อยรับและประมวลผลในเวลาของตัวเอง จุดเด่นของ Azure Container Apps คือเป็นแพลตฟอร์ม Serverless Container ที่รองรับ KEDA (Kubernetes Event-driven Autoscaling) ในตัว ทำให้แอปพลิเคชันขยายจำนวน Replicas ตามความยาวคิวของข้อความได้อัตโนมัติ และสามารถ Scale ลงไปเหลือศูนย์ได้เมื่อไม่มีงาน ซึ่งช่วยประหยัดค่าใช้จ่ายอย่างมหาศาล นอกจากนี้การแยกความสัมพันธ์ระหว่างบริการ (Decoupling) ยังช่วยให้บางส่วนของระบบล่มได้โดยไม่กระทบระบบโดยรวม ทำให้ระบบมีความเสถียรและทนทานมากขึ้น

ควรเลือกใช้ Azure Storage Queue, Service Bus, Event Hubs หรือ Event Grid ในกรณีใด?

การเลือกตัวกลางส่งเหตุการณ์ขึ้นอยู่กับลักษณะงาน ถ้าเป็นคำสั่งธุรกิจที่ห้ามหาย เช่น การสร้างใบสั่งซื้อ ควรใช้ Azure Service Bus Queue เพราะรับประกันการส่งแบบ FIFO และมีระบบ Dead Letter Queue รองรับ ขนาดข้อความสูงสุด 1 เมกะไบต์ ราคาปานกลาง ถ้าเป็นคิวงานง่าย ๆ ปริมาณสูง ให้ใช้ Azure Storage Queue ซึ่งถูกที่สุดแต่ไม่รับประกันลำดับและขนาดข้อความจำกัดที่ 64 กิโลไบต์ ถ้าเป็นสตรีมข้อมูลปริมาณมหาศาล เช่น บันทึกพฤติกรรมผู้ใช้เป็นล้านเหตุการณ์ต่อวินาที ให้ใช้ Azure Event Hubs ที่คิดราคาตาม Throughput ส่วน Azure Event Grid เหมาะกับการตอบสนองเหตุการณ์ระหว่างบริการ Azure เช่น เมื่อไฟล์ขึ้นไปที่ Blob Storage แล้วให้เรียก Container App มาประมวลผลทันที โดยจ่ายตามจำนวนเหตุการณ์

KEDA ทำงานกับ Azure Container Apps อย่างไร และต้องเขียนโค้ดเพิ่มหรือไม่?

KEDA หรือ Kubernetes Event-driven Autoscaling ทำงานในเบื้องหลังของ Azure Container Apps โดยอัตโนมัติ ผู้ใช้ไม่จำเป็นต้องติดตั้งหรือจัดการเอง เพียงกำหนด Scale Rule ในไฟล์ Template ของ Container App เท่านั้น เช่น ระบุว่าให้ขยายตามความยาวคิวของ Azure Service Bus โดยทุก ๆ สิบข้อความให้เพิ่มหนึ่ง Replicas พร้อมกำหนดจำนวน Replicas ขั้นต่ำเป็นศูนย์และขั้นสูงสุดเป็นสิบ จากนั้นระบบจะจัดการขยายและย่อตัวเองทั้งหมดโดยไม่ต้องเขียนโค้ดขยายตัวเองเลย ข้อดีคือแอปพลิเคชันสามารถตอบสนองตามปริมาณเหตุการณ์ที่รอประมวลผลได้แบบเรียลไทม์ และเมื่อไม่มีงานระบบจะ Scale ลงเหลือศูนย์ ช่วยประหยัดค่าใช้จ่ายได้อย่างมีนัยสำคัญ

Idempotency คืออะไร และเหตุใดจึงสำคัญในระบบ Event Driven?

Idempotency หรือความสามารถในการประมวลผลข้อความเดิมซ้ำโดยไม่เกิดผลข้างเคียง เป็นสิ่งที่มือใหม่มักมองข้าม เหตุที่ต้องสำคัญเพราะระบบคิวทุกตัวมีโอกาสส่งข้อความซ้ำตามหลักการ At-least-once delivery หากไม่จัดการให้ดี อาจเกิดความเสียหายร้ายแรงได้ เช่น มีระบบที่ตัดเงินซ้ำกับลูกค้าเพราะไม่มีการตรวจสอบข้อความที่ประมวลผลไปแล้ว ทำให้เสียหายทั้งค่าใช้จ่ายและความเชื่อมั่นจากลูกค้า แนวทางการออกแบบที่ดีคือทุกเหตุการณ์ต้องมีรหัสเฉพาะ (Unique ID) แล้วเก็บรหัสของเหตุการณ

แนะนำเพิ่มเติม

🎯 เปิดบัญชี XM Forex → สมัคร

📱 แอป iCafeFX → ดาวน์โหลด

📊 สัญญาณฟรี → รับสัญญาณ

📚 คู่มือเทรด → SiamCafeBook

🤝 สมัคร Partner XM → pipaffiliates.com/c?c=72816&l=th&p=6