Communication Concepts - System Design, Simply Explained

บทความนี้จะอธิบายพื้นฐานของ System Design โดยต่อยอดจากตัวอย่าง Gym Application เพื่อให้เห็นภาพว่า เมื่อระบบเริ่มเติบโตและถูกแยกออกเป็นหลาย Service แต่ละ Service จะสื่อสารและทำงานร่วมกันอย่างไร งานแบบไหนควรสื่อสารแบบ Synchronous งานแบบไหนควรประมวลผลแบบ Asynchronous รวมถึงอธิบาย Concept พื้นฐานต่าง ๆ ที่ควรรู้ เช่น API Communication, Messaging, Real-time Communication, Reliability และ AI Concepts

บทความอื่นๆ ที่เกี่ยวข้องกัน

• Core Infrastructure Concepts - System Design, Simply Explained
• Distributed Systems Concepts - System Design, Simply Explained
• Database & Storage Concepts - System Design, Simply Explained

จากบทความก่อนหน้า Gym Application มีความสามารถหลักประมาณนี้

• ลูกค้าสมัครสมาชิกและเลือกแพ็กเกจได้
• ลูกค้าชำระเงินค่าสมาชิกได้
• ลูกค้าจองคลาสและเทรนเนอร์ได้
• ลูกค้าสแกน QR Code เพื่อเข้ายิมได้
• Admin อัปโหลดรูปคลาส รูปเทรนเนอร์ และเอกสารสัญญาได้
• ระบบสามารถดูประวัติการเปลี่ยนแปลงของสมาชิกได้

ตอนนี้ระบบแยกส่วนออกเป็น Services ย่อยๆ ตามนี้

• Member Service
• Booking Service
• Payment Service
• Check-in Service
• Notification Service
• Search Service
• AI Assistant Service

SOAP

SOAP หรือ Simple Object Access Protocol คือ Protocol สำหรับแลกเปลี่ยนข้อมูลระหว่างระบบ โดยใช้ XML เป็นรูปแบบ Message และมี Contract ที่อธิบาย API ผ่าน WSDL

SOAP จะมักเจอในระบบ Enterprise หรือระบบเก่าที่ต้องการ Contract ชัดเจน มีมาตรฐานเรื่อง Security, Transaction, Header และ Error Format ชัดเจน

ลองดู Use Case ในระบบ Gym Application ถ้าบริษัทต้องเชื่อมต่อกับระบบประกันสุขภาพขององค์กรขนาดใหญ่ เพื่อให้พนักงานใช้สิทธิ์ Fitness Benefit ได้และระบบประกันมีการเปิด API แบบ SOAP ให้ไปเชื่อมต่อ

Flow จะเป็นแบบนี้

• Member Service ต้องตรวจสอบสิทธิ์ Fitness Benefit
• Member Service สร้าง SOAP Request เป็น XML ตาม WSDL ของระบบประกัน
• ระบบประกันตอบกลับเป็น SOAP Response
• Member Service แปลงผลลัพธ์เป็นข้อมูลภายใน เช่น eligible, benefit_limit, expired_at

ข้อดี

• SOAP มี Contract ชัดเจนผ่าน WSDL ทำให้ระบบที่ต้อง Integrate กันแบบเป็นทางการรู้ว่า Request และ Response ต้องมีรูปแบบอย่างไร
• เหมาะกับระบบ Enterprise ที่ต้องการมาตรฐานเรื่อง Security, Header, Error และ Operation ที่เข้มงวด
• เครื่องมือหลายตัวสามารถ Generate Client Code จาก WSDL ได้ ช่วยลดงานเขียน Request XML เอง

Trade-off

• SOAP หนักกว่า REST เพราะ XML และ Envelope มี Overhead สูงกว่า JSON ทั่วไป
• การ Debug อ่านยากกว่า เพราะ Payload ยาวและมีโครงสร้างซับซ้อน
• ไม่เหมาะกับ Mobile API สมัยใหม่ที่ต้องการความเรียบง่ายและ Latency ต่ำ เว้นแต่ต้องเชื่อมกับระบบที่บังคับใช้ SOAP อยู่แล้ว

REST

REST หรือ Representational State Transfer คือแนวทางออกแบบ API โดยใช้ Resource เป็นหลัก และใช้ HTTP Method เพื่อบอก Action เช่น GET, POST, PUT, PATCH และ DELETE

• REST เป็นรูปแบบที่พบบ่อยมากสำหรับ Client คุยกับ Backend เพราะเข้าใจง่าย ใช้ HTTP ได้ตรงไปตรงมา และมักจะส่งข้อมูลเป็น JSON

ลองดู Use Case ในระบบ Gym Application Mobile App และ Web App เรียกใช้งาน REST API กัน

• GET /classes เพื่อดูรายการคลาส
• GET /classes/123 เพื่อดูรายละเอียดคลาส
• POST /bookings เพื่อจองคลาส
• PATCH /members/me เพื่อแก้ไขข้อมูลสมาชิก
• DELETE /bookings/456 เพื่อยกเลิกการจอง

ข้อดี

• REST เรียบง่ายและเข้ากับ HTTP โดยตรง ทำให้ Client, Server, Proxy, Cache, Load Balancer และ Monitoring Tool รองรับได้ดี
• เหมาะกับ Public API และ Mobile/Web API เพราะทีมส่วนใหญ่เข้าใจ Pattern นี้อยู่แล้ว
• สามารถใช้ HTTP Status Code, Header, Cache-Control และ Authentication แบบมาตรฐานได้

Trade-off

• ถ้า Endpoint คืนข้อมูลใหญ่เกินไป Client จะได้ Field ที่ไม่ได้ใช้ ทำให้สิ้นเปลือง Bandwidth โดยเฉพาะ Mobile Network
• REST ไม่ได้บังคับ Contract แบบเข้มงวดเท่า gRPC หรือ SOAP ถ้าไม่มี OpenAPI, Versioning และ Backward Compatibility ที่ดี การเปลี่ยน API จะทำให้กระทบ Client ได้ง่าย

gRPC

gRPC คือ Framework สำหรับการสื่อสารระหว่าง Service โดยแนวคิดคือให้ Service หนึ่งสามารถเรียก Function ของอีก Service ผ่าน Network ได้ คล้ายกับการเรียก Function ภายในโปรแกรม

gRPC ใช้ไฟล์ .proto เพื่อกำหนด Service, Method รวมถึงโครงสร้างของ Request และ Response จากนั้นสามารถ Generate Client และ Server Code สำหรับภาษาต่าง ๆ ได้ ทำให้ Service ทั้งสองฝั่งมี Contract ในการสื่อสารที่ชัดเจน

ข้อมูลที่ส่งผ่าน gRPC จะถูก Serialize ด้วย Protocol Buffers (Protobuf) ซึ่งเป็น Binary Format ทำให้ Payload มีขนาดเล็กกว่า JSON และ gRPC โดยทั่วไปใช้ HTTP/2 เป็น Transport

ลองดู Use Case ในระบบ Gym Application ถ้าระบบแยกเป็น Microservices ภายใน เช่น Booking Service ต้องเรียก Member Service และ Payment Service การใช้ gRPC อาจเหมาะกว่า REST สำหรับ Internal Service Communication

Flow จะเป็นแบบนี้

• Booking Service เรียก MemberService.GetMembershipStatus(member_id)
• Member Service ตอบกลับสถานะสมาชิกและสิทธิ์การจอง
• Booking Service เรียก PaymentService.AuthorizePayment(payment_method_id, amount)
• Payment Service ตอบกลับผลการกันวงเงิน

เพราะเป็นการคุยกันระหว่าง Service ภายใน เราให้ความสำคัญกับ Contract, Performance, Timeout, Retry และ Observability

ข้อดี

• gRPC มี Contract ชัดเจนผ่าน proto และ Generate Code ได้หลายภาษา ทำให้ลดความผิดพลาดจากการส่ง Payload ผิดรูปแบบ
• Payload แบบ Protobuf มีขนาดเล็กและ Serialize ได้เร็วกว่า JSON ในหลายกรณี
• รองรับ Streaming ได้หลายแบบ เช่น Server Streaming, Client Streaming และ Bidirectional Streaming จึงเหมาะกับงาน Internal Real-time หรือ Data Pipeline

Trade-off

• gRPC ไม่เป็นมิตรกับ Browser และ Human Debug เท่า REST เพราะ Payload เป็น Binary และต้องมี Tool ช่วยดู
• ต้องดูแล proto versioning ให้ดี เพราะการเปลี่ยน Field หรือ Service Contract ผิดจะกระทบ Service หลายตัว
• ถ้าระบบยังเล็กหรือทีมยังไม่พร้อม การใช้ gRPC อาจเพิ่มความซับซ้อนของ Build, Deployment, Gateway และ Observability โดยไม่จำเป็น

GraphQL

GraphQL คือ Query Language และ Runtime สำหรับ API ที่ให้ Client ระบุได้ว่าต้องการข้อมูลอะไรบ้างใน Request เดียว

GraphQL เหมาะกับหน้า UI ที่ต้องประกอบข้อมูลจากหลาย Resource และ Client แต่ละแบบต้องการข้อมูลไม่เท่ากัน เช่น Mobile ต้องการข้อมูลน้อยกว่า Web หรือ Admin ต้องการ Field มากกว่าลูกค้า

ลองดู Use Case ในระบบ Gym Application หน้า Home ของ Mobile App ต้องแสดงข้อมูลหลายส่วนพร้อมกัน เช่น

• ข้อมูลสมาชิกปัจจุบัน
• คลาสแนะนำวันนี้
• เทรนเนอร์ยอดนิยม
• โปรโมชันที่เกี่ยวข้อง
• จำนวน Notification ที่ยังไม่ได้อ่าน

ถ้าใช้ REST อาจต้องเรียกหลาย Endpoint แต่ถ้าใช้ GraphQL Client สามารถส่ง Query เดียวเพื่อเลือก Field ที่ต้องการจริง ๆ เช่น class name, start_time, trainer name และ remaining_seats โดยไม่ต้องเอาข้อมูลทั้งหมดของแต่ละ Resource กลับมา

ข้อดี

• GraphQL ลดปัญหา Over-fetching และ Under-fetching เพราะ Client เลือก Field ที่ต้องการได้เอง
• ช่วยรวมข้อมูลหลาย Resource ใน Request เดียว ทำให้หน้า UI ที่ซับซ้อนโหลดข้อมูลได้สะดวกขึ้น
• Schema ของ GraphQL ทำหน้าที่เป็น Contract กลางระหว่าง Frontend และ Backend และช่วยให้ Tooling อย่าง GraphQL Playground หรือ Code Generator ทำงานได้ดี

Trade-off

• Backend ซับซ้อนขึ้น เพราะต้องออกแบบ Schema, Resolver, Authorization, Pagination, Error Handling และ Query Complexity Limit
• ถ้าไม่ป้องกันให้ดี Client จะเรียก Query ลึกหรือหนักเกินไปจน Backend และ Database ทำงานหนัก
• Caching ทำได้ยากกว่า REST แบบ Resource URL ตรง ๆ เพราะ Request หนึ่งอาจมี Query Shape แตกต่างกันมาก

Webhook

Webhook คือวิธีที่ระบบหนึ่งส่งข้อมูลไปยัง HTTP Endpoint ของอีกระบบอัตโนมัติเมื่อมี Event เกิดขึ้น โดยระบบปลายทางไม่ต้องคอย Poll เพื่อเช็กว่ามีข้อมูลเปลี่ยนแปลงหรือไม่

Webhook มักจะใช้กับการ Integrate กับระบบภายนอก เช่น Payment Gateway, Email Provider, SMS Provider, CRM หรือระบบ Automation

ลองดู Use Case ในระบบ Gym Application เมื่อลูกค้าชำระเงินผ่าน Payment Gateway

Flow จะเป็นแบบนี้

• Payment Service สร้าง payment_attempt
• Payment Gateway รับคำขอและคืนสถานะ pending
• เมื่อการชำระเงินสำเร็จ Payment Gateway เรียก Webhook มาที่ POST /webhooks/payments
• Payment Service ตรวจข้อมูลผ่าน Webhook
• Payment Service อัปเดตสถานะ payment_succeeded และส่ง Event ต่อให้ Contract Service เปิดสิทธิ์สมาชิก

ข้อดี

• Webhook ลดการ Poll เพราะ External System เป็นคนเรียกกลับมาเมื่อมี Event เกิดขึ้น
• เหมาะกับ Workflow ที่ไม่ได้ผลลัพธ์ทันที เช่น Payment, Subscription, Delivery Status, Email Bounce หรือ KYC Verification
• ช่วยให้ระบบของเราตอบสนองต่อ Event ภายนอกได้ใกล้เคียง Real-time โดยไม่ต้องยิง API ถามซ้ำตลอดเวลา

Trade-off

• Webhook ต้องออกแบบ Security ให้ดี เช่น ตรวจ Signature, Timestamp, Replay Protection และ IP Allowlist หากเหมาะสม
• ต้องรองรับ Retry และ Duplicate Event เพราะ Provider อาจส่ง Webhook ซ้ำเมื่อไม่ได้รับ Response 2xx
• ต้องทำ Idempotency เสมอ เช่น payment_succeeded Event เดิมถูกส่งมา 3 ครั้ง ระบบต้องไม่เปิดสัญญาซ้ำหรือส่ง Receipt ซ้ำโดยไม่ตั้งใจ

Message Queue

Message Queue คือ Component ที่ใช้พัก Message จาก Producer ไว้ชั่วคราว เพื่อให้ Consumer หรือ Worker นำไปประมวลผลภายหลัง

แนวคิดหลักคือ Producer ไม่จำเป็นต้องรอให้ Consumer ทำงานเสร็จ Producer เพียงส่ง Message เข้า Queue แล้วสามารถทำงานต่อได้ทันที ส่วน Consumer จะค่อย ๆ ดึง Message จาก Queue ไปประมวลผล

โดยทั่วไป Message แต่ละรายการจะถูกส่งให้ Consumer หรือ Worker หนึ่งตัวในกลุ่มเดียวกันเพื่อประมวลผล จึงเหมาะกับงานประเภท Work Distribution หรือ Background Processing

ลองดู Use Case ในระบบ Gym Application เมื่อลูกค้าจองคลาสสำเร็จ Booking Service ไม่ควรต้องรอทุกอย่างให้เสร็จถึง Response กลับไปได้

Flow จะเป็นแบบนี้

• Booking Service สร้าง booking สำเร็จ และ Response กลับไปยัง Client
• Booking Service ส่ง Message booking_confirmed เข้า Queue
• Notification Worker ดึง Message ไปส่ง Push Notification และ Email
• Analytics Worker ดึง Message ไปบันทึกข้อมูลสำหรับ Report

ข้อดี

• Message Queue ช่วยแยก Producer และ Consumer ออกจากกัน ทำให้ Service ต้นทางไม่จำเป็นต้องรอ Service ปลายทางทำงานเสร็จ และยังช่วยรองรับ Traffic Spike ได้ เช่น ตอนเปิดจองคลาสยอดนิยมที่มี Booking Event จำนวนมากเข้ามาพร้อมกัน Message สามารถถูกพักไว้ใน Queue แล้วให้ Worker ค่อย ๆ ประมวลผลตาม Capacity ที่มี
• Producer และ Consumer สามารถ Scale แยกกันได้ ถ้า Queue ยาวขึ้นก็เพิ่ม Worker ได้โดยไม่ต้องเพิ่ม Booking Service

Trade-off

• ระบบกลายเป็น Asynchronous ทำให้ผลลัพธ์บางอย่างไม่ได้เกิดทันที เช่น ลูกค้าอาจจองสำเร็จก่อน แล้ว Notification ตามมาทีหลัง
• ต้องออกแบบเรื่อง Retry, Duplicate Message, Idempotency, Ordering และ Monitoring ให้ดี เพราะ Message อาจถูกส่งซ้ำ ประมวลผลซ้ำ หรือติดค้างใน Queue ได้

Message Broker

Message Queue คือกลไกสำหรับพัก Message ไว้ชั่วคราว เพื่อให้ Consumer นำไปประมวลผลภายหลัง ส่วน Message Broker คือระบบตัวกลางที่ช่วยจัดการการส่ง Message ระหว่าง Producer และ Consumer โดยสามารถทำได้มากกว่าการพัก Message เช่น Routing, Queuing, Retry, Monitoring และการกระจาย Message ไปยังปลายทางต่าง ๆ

ตัวอย่างระบบ Messaging ที่พบบ่อย เช่น RabbitMQ, Apache Kafka, Amazon SQS/SNS, Google Pub/Sub และ Redis Streams โดยแต่ละระบบมีแนวคิดและความสามารถแตกต่างกัน บางระบบเหมาะกับ Queue สำหรับกระจายงานให้ Worker ขณะที่บางระบบเหมาะกับ Topic, Event Stream, Partition และการ Replay Event

ลองดู Use Case ในระบบ Gym Application เมื่อ Booking Service สร้าง Event booking_confirmed ระบบไม่ควรเรียก Notification Service, Analytics Service และ Reminder Service แบบ Direct Call โดยตรง เพราะถ้า Service ปลายทางบางตัวทำงานช้าหรือล่ม จะส่งผลกระทบกลับมายัง Booking Service

เราสามารถวาง Message Broker ไว้ตรงกลางได้แบบนี้

• Booking Service ส่ง Message booking_confirmed เข้า Message Broker
• Message Broker เก็บและกระจาย Message ไปยัง Queue หรือ Topic ที่เกี่ยวข้อง
• Notification Worker รับ Message เพื่อส่ง Email และ Push Notification
• Analytics Worker รับ Message เพื่ออัปเดต Report
• Reminder Worker รับ Message เพื่อสร้าง Reminder ก่อนคลาสเริ่ม

ถ้า Notification Worker ล่ม Message ที่เกี่ยวข้องยังสามารถถูกเก็บไว้เพื่อรอประมวลผลภายหลังได้ ขณะที่ Analytics Worker และ Reminder Worker ยังสามารถทำงานต่อได้โดยไม่ต้องรอ Notification Worker

ข้อดี

• Message Broker ช่วยลด Coupling ระหว่าง Service เพราะ Producer ไม่จำเป็นต้องรู้ว่า Consumer อยู่ที่ไหน มีกี่ตัว หรือทำงานเร็วแค่ไหน
• ช่วยเพิ่ม Reliability ผ่านกลไกอย่าง Persistence, Acknowledgement, Retry และ Dead-Letter Queue ขึ้นอยู่กับความสามารถของระบบที่เลือกใช้
• รองรับ Messaging Pattern ได้หลายแบบ เช่น Queue สำหรับกระจายงานให้ Worker, Pub/Sub สำหรับกระจาย Event ให้หลายระบบ และ Event Stream สำหรับเก็บ Event ที่สามารถอ่านย้อนหลังหรือ Replay ได้

Trade-off

• Message Broker กลายเป็น Infrastructure สำคัญของระบบ ถ้า Broker มีปัญหาหรือ Config ผิด งาน Asynchronous จำนวนมากอาจหยุดหรือเกิดความล่าช้า
• ต้องดูแล Operation เพิ่ม เช่น Cluster, Partition, Consumer Lag, Retention, Retry Policy, DLQ, Schema Compatibility และ Monitoring
• ต้องเข้าใจ Delivery Semantics เช่น At-most-once และ At-least-once รวมถึงข้อจำกัดของ Exactly-once เพราะในระบบจริง Message อาจถูกส่งหรือประมวลผลซ้ำได้ จึงควรออกแบบ Consumer ให้รองรับ Idempotency

MQTT และ AMQP

MQTT และ AMQP เป็น Protocol สำหรับ Messaging ที่มักจะใช้ร่วมกับ Message Broker มี Use Case การใช้งานดังนี้

MQTT หรือ Message Queuing Telemetry Transport เป็น Protocol ที่ออกแบบให้มี Overhead ต่ำ เหมาะกับอุปกรณ์ที่มีข้อจำกัดด้าน Network, Bandwidth หรือ Resource เช่น IoT Device, Sensor และอุปกรณ์ที่ต้องเชื่อมต่อกับระบบเป็นเวลานาน

MQTT ใช้รูปแบบ Publish/Subscribe โดย Producer ส่ง Message ไปยัง Topic และ Consumer ที่ Subscribe Topic นั้นจะได้รับ Message

ตัวอย่างใน Gym Application เช่น เครื่องสแกน QR Code, Turnstile หรือ Sensor นับจำนวนคน จะส่ง Event ไปยัง Topic เช่น

• gym/branch-1/checkins
• gym/branch-1/occupancy

จากนั้น Check-in Service หรือ Realtime Service สามารถ Subscribe เพื่อรับข้อมูลไปประมวลผลต่อได้

AMQP หรือ Advanced Message Queuing Protocol เป็น Protocol สำหรับ Messaging ที่เน้นการส่ง Message ระหว่าง Application และเหมาะกับระบบ Backend ที่ต้องการ Reliability และการควบคุมการส่ง Message มากขึ้น

ตัวอย่างเช่น Payment Service ส่ง payment_succeeded ไปยัง Message Broker แล้ว Broker สามารถ Route Message ไปยัง Consumer ที่เกี่ยวข้อง เช่น Contract Service, Notification Service และ Reporting Service

ข้อดี

• MQTT มี Overhead ต่ำ เหมาะกับ IoT Device และ Network ที่มีข้อจำกัด
• AMQP เหมาะกับ Backend Messaging ที่ต้องการ Routing, Acknowledgement และ Reliability
• ทั้งสองช่วยให้ Producer และ Consumer สื่อสารกันแบบ Asynchronous ผ่าน Broker ได้

Trade-off

• MQTT เน้น Publish/Subscribe และความเรียบง่าย จึงเหมาะกับ Messaging Pattern ที่ไม่ซับซ้อน ขณะที่ AMQP รองรับความสามารถด้าน Messaging เช่น Routing และ Acknowledgement ที่หลากหลายกว่า
• AMQP มีความซับซ้อนและ Overhead มากกว่า MQTT จึงอาจไม่เหมาะกับอุปกรณ์ที่มี Resource จำกัด
• การเลือกใช้ควรดูจากประเภทของ Client, Reliability ที่ต้องการ และ Messaging Pattern ของระบบ

Pub/Sub

Pub/Sub หรือ Publish-Subscribe คือรูปแบบการสื่อสารที่ Producer ส่ง Event ไปยัง Topic แล้ว Consumer หลายตัวที่ Subscribe Topic นั้นจะได้รับสำเนาของ Event เพื่อนำไปทำงานของตัวเอง

ความต่างสำคัญระหว่าง Queue กับ Pub/Sub คือ Queue มักใช้ให้งานหนึ่งชิ้นถูกประมวลผลโดย Consumer หนึ่งตัวในกลุ่มเดียวกัน ส่วน Pub/Sub ใช้ Fan-out Event เดียวไปยังหลาย Subscriber ที่เป็นอิสระต่อกัน

ลองดู Use Case ในระบบ Gym Application เมื่อ Booking Service สร้าง Event class_booked แล้วส่งไป Topic ชื่อ booking-events ระบบอื่นที่ Subscribe Topic นี้หลายตัว เช่น

• Notification Service ส่งข้อความยืนยันให้ลูกค้า
• Reporting Service อัปเดต Dashboard ของ Admin
• Recommendation Service ปรับคะแนนความนิยมของคลาส
• Member Timeline Service เพิ่ม Activity ลงในประวัติสมาชิก

Booking Service ไม่ต้องรู้ว่ามีใครฟัง Event นี้อยู่บ้าง หน้าที่ของ Booking Service คือประกาศว่าเกิดอะไรขึ้น ส่วนระบบอื่นตัดสินใจเองว่าจะตอบสนองอย่างไร

ข้อดี

• Pub/Sub ช่วยให้ Service ใหม่เข้ามา React กับ Event เดิมได้โดยไม่ต้องแก้ Service ต้นทาง
• เหมาะกับ Event ที่มีหลายระบบต้องใช้ร่วมกัน เช่น booking_created, payment_succeeded, member_upgraded หรือ check_in_completed
• ช่วยลดการเรียก API แบบ Synchronous หลายทอด ซึ่งมักทำให้ Latency สูงและเกิด Cascading Failure ได้ง่าย

Trade-off

• เมื่อมี Subscriber หลายตัว การ Debug จะยากขึ้น เพราะ Event เดียวอาจทำให้เกิด Side Effect หลายจุด
• ต้องดูแล Schema ของ Event ให้ดี ถ้าเปลี่ยน Field หรือความหมายของ Event โดยไม่รองรับ Backward Compatibility ระบบที่ Subscribe อยู่เดิมจะพังได้
• ถ้า Subscriber บางตัวล่าช้า ข้อมูลในแต่ละระบบอาจไม่อัปเดตพร้อมกันทันที จึงต้องยอมรับ Eventual Consistency

Dead-Letter Queue

Dead-Letter Queue หรือ DLQ คือ Queue สำหรับเก็บ Message ที่ประมวลผลไม่สำเร็จหลังจาก Retry ครบจำนวนที่กำหนด

ปัญหาที่ DLQ ช่วยแก้คือ Poison Message เช่น Message ที่ข้อมูลผิดรูปแบบ, อ้างอิง Resource ที่ไม่มีอยู่จริง หรือทำให้ Worker Error ทุกครั้ง หากปล่อยให้ Retry ไม่รู้จบ Message แบบนี้อาจทำให้ Queue หลักติดขัดและทำให้งานอื่นช้าตามไปด้วย

ลองดู Use Case ในระบบ Gym Application Notification Worker ได้ Message ให้ส่ง SMS แต่ Payload ไม่มี phone_number หรือมี Template ID ที่ถูกลบไปแล้ว

ถ้าไม่มี DLQ Worker อาจ Retry Message นี้ซ้ำไปเรื่อย ๆ และกิน Capacity ของ Worker โดยไม่เกิดประโยชน์

ถ้ามี DLQ Flow จะเป็นแบบนี้

• Worker ดึง Message จาก Queue หลัก
• ส่ง SMS ไม่สำเร็จ
• Retry ตาม Policy เช่น 3 ครั้ง
• ถ้ายังไม่สำเร็จ ย้าย Message ไป Dead-Letter Queue
• ทีมดูแลระบบตรวจ DLQ เพื่อแก้ข้อมูล, แก้ Bug หรือ Redrive Message กลับไปประมวลผลใหม่

ข้อดี

• DLQ ช่วยแยก Message ที่มีปัญหาออกจาก Queue หลัก ทำให้งานอื่นยังประมวลผลต่อได้ตามปกติ
• ช่วยให้ทีมตรวจสอบปัญหาได้จากข้อมูลจริง เช่น Payload ที่พัง, Error จาก Provider หรือ Bug ใน Worker
• เหมาะกับระบบที่ต้องการ Reliability สูง เพราะ Message ที่ล้มเหลวไม่หายเงียบ แต่ถูกแยกไว้ให้ติดตามต่อ

Trade-off

• DLQ ไม่ได้แก้ปัญหาเอง ถ้าไม่มี Alert, Dashboard และ Process สำหรับตรวจ DLQ Message ก็จะค้างอยู่เฉย ๆ
• ต้องกำหนด Retry Policy ให้เหมาะสม ถ้า Retry น้อยเกินไป Message ที่อาจสำเร็จในครั้งถัดไปจะถูกย้ายไป DLQ เร็วเกินไป แต่ถ้า Retry มากเกินไป Queue หลักจะเสีย Capacity กับงานที่น่าจะไม่สำเร็จ

Backpressure

Backpressure คือกลไกสำหรับควบคุมอัตราการส่งหรือรับงาน เมื่อระบบปลายทางประมวลผลได้ช้ากว่าระบบต้นทาง เพื่อป้องกันไม่ให้งานสะสมจนเกิน Capacity ของระบบ

ถ้าไม่มี Backpressure ระบบต้นทางที่เร็วกว่า Consumer มาก ๆ จะส่งงานเข้า Queue หรือ Stream เรื่อย ๆ จน Memory เต็ม Queue ยาวขึ้นเรื่อย ๆ และ Latency ของงานทั้งหมดพุ่งสูง

ลองดู Use Case ในระบบ Gym Application ช่วงปีใหม่ระบบส่ง Campaign Promotion ให้สมาชิกจำนวนมาก Notification Service ต้องส่ง Push, Email และ SMS พร้อมกัน

ปัญหาคือ SMS Provider รับได้แค่ 500 Request ต่อวินาที แต่ระบบสร้างงานได้ 5,000 Message ต่อวินาที ถ้า Worker ส่งแบบไม่จำกัด Provider จะเริ่ม Timeout และ Worker จะ Retry จำนวนมากจนระบบแย่กว่าเดิม

Backpressure ทำได้หลายแบบ เช่น

• จำกัดจำนวน Message ที่ Worker ดึงจาก Queue ต่อรอบ
• ใช้ Bounded Queue เมื่อเต็มแล้วให้ Producer รอหรือปฏิเสธงานบางประเภท
• ปรับ Rate การส่ง SMS ตาม Error Rate หรือ Response Time ของ Provider
• แยก Priority Queue เพื่อให้ Notification สำคัญ เช่น Payment Receipt ไปก่อน Campaign Promotion

ข้อดี

• Backpressure ทำให้ Overload มองเห็นและควบคุมได้ แทนที่จะปล่อยให้ปัญหาสะสมจนระบบล่ม
• ช่วยป้องกัน Consumer, Queue, Provider และ Database ไม่ให้ถูกงานจากต้นทางที่เร็วเกินไปกดจนหมดทรัพยากร

Trade-off

• เมื่อเปิด Backpressure งานบางอย่างจะช้าลงหรือถูกปฏิเสธ ทำให้ต้องออกแบบ UX และ Business Rule ให้รองรับ
• ถ้าปรับ Threshold ไม่ดี ระบบอาจชะลอมากเกินไปจน Throughput ต่ำ หรือชะลอน้อยเกินไปจนยังเกิด Overload อยู่

WebSocket

WebSocket คือ Protocol สำหรับเปิด Connection ระหว่าง Client กับ Server ค้างไว้ เพื่อให้ทั้งสองฝั่งสามารถส่งข้อมูลหากันได้ตลอดเวลาผ่าน Connection เดียว

หลังจากเชื่อมต่อสำเร็จ Client ส่งข้อมูลไป Server ได้ และ Server ก็ Push ข้อมูลกลับมาหา Client ได้ทันที โดยไม่ต้องให้ Client Poll API ซ้ำ ๆ

ลองดู Use Case ในระบบ Gym Application ตอนเปิดจองคลาสยอดนิยม ลูกค้าอยากเห็นจำนวนที่นั่งคงเหลือแบบใกล้เคียง Real-time และบางฟีเจอร์อาจต้องโต้ตอบสองทาง เช่น

• Live Chat กับเทรนเนอร์
• Live Booking Status
• Admin Dashboard ดู Check-in ที่เกิดขึ้นตอนนี้
• หน้าจอ Reception แสดงสถานะสมาชิกหลังสแกน QR Code

Flow จะเป็นแบบนี้

• Mobile App เปิด WebSocket ไปยัง Realtime Service
• Realtime Service เก็บว่า user_id นี้เชื่อมต่ออยู่ที่ Server เครื่องใด
• เมื่อ Booking Service ส่ง Event class_seat_updated เข้าระบบ Pub/Sub
• Realtime Service รับ Event แล้ว Push ไปยัง Client ที่กำลังดูคลาสนั้น

ข้อดี

• WebSocket เหมาะกับงาน Real-time ที่ต้องสื่อสารสองทิศทางและต้องการ Latency ต่ำ เช่น Chat, Collaboration, Live Status และ Trading
• ลดภาระจาก Polling เพราะ Server ส่งข้อมูลเมื่อมี Event จริง ไม่ต้องให้ Client ยิง Request ถี่ ๆ เพื่อถามว่ามีข้อมูลใหม่หรือยัง

Trade-off

• Connection ของ WebSocket เป็น Long-lived และ Stateful ทำให้ Scale ยากกว่า HTTP Request ปกติ
  ต้องดูแล Connection Registry, Heartbeat, Reconnect, Authentication, Authorization และการ Route Message ไปยัง Server ที่ถือ Connection ของ User นั้นอยู่
• ถ้า Client หรือ Server รับ Message ไม่ทัน ต้องระวัง Buffer โตจน Memory สูง โดยเฉพาะระบบที่ Push ข้อมูลเร็วมาก

Server-Sent Events (SSE)

Server-Sent Events หรือ SSE คือวิธีให้ Server Push Event ไปยัง Client ผ่าน HTTP Connection ที่เปิดค้างไว้ โดยเป็นการสื่อสารทางเดียวจาก Server ไป Client

Client ใช้ EventSource เปิด Connection ไปยัง Server แล้ว Server ส่ง Event กลับมาในรูปแบบ text/event-stream หาก Connection หลุด Browser สามารถ Reconnect ได้ และสามารถใช้ Last-Event-ID เพื่อช่วย Resume Event บางกรณีได้

ลองดู Use Case ในระบบ Gym Application บาง Feature ต้องการให้ Server ส่งข้อมูลอย่างเดียว ไม่จำเป็นต้องให้ Client ส่งกลับผ่าน Connection เดียวกัน เช่น

• Admin Dashboard แสดงยอด Check-in วันนี้แบบ Live
• หน้า Booking แสดงจำนวนที่นั่งคงเหลือ
• AI Assistant Streaming คำตอบทีละช่วง
• หน้าจอ Reception รับ Event ว่าสมาชิกคนใด Check-in สำเร็จ
• ถ้า Feature เป็นแค่ Server Push แบบอ่านอย่างเดียว SSE มักเรียบง่ายกว่า WebSocket เพราะยังทำงานบน HTTP Model ได้ตรงไปตรงมา

ข้อดี

• SSE เหมาะกับงานที่ Server ต้อง Push ข้อมูลลง Client แบบทางเดียว เช่น Notification Feed, Dashboard Update, Stock Price หรือ AI Response Streaming
• Client API เรียบง่ายและมี Reconnect ในตัว จึงลดงานฝั่ง Frontend เมื่อเทียบกับการจัดการ WebSocket เองทั้งหมด

Trade-off

• SSE ไม่เหมาะกับงานที่ต้องสื่อสารสองทิศทางถี่ ๆ เช่น Chat หรือ Multiplayer เพราะ Client ต้องส่งข้อมูลกลับผ่าน HTTP Request แยก
• ถ้าใช้ผ่าน HTTP/1.1 ต้องระวังจำนวน Connection ต่อ Domain โดยเฉพาะผู้ใช้เปิดหลาย Tab พร้อมกัน
• ระบบยังต้องจัดการเรื่อง Authentication, Authorization, Timeout, Proxy Buffering และการ Resume Event ที่ส่งไม่ถึง Client

Circuit Breaker

Circuit Breaker คือ Pattern ที่ใช้หยุดการเรียก Dependency ชั่วคราว เมื่อพบว่า Dependency นั้นกำลังมีปัญหาหรือเกิด Error ต่อเนื่อง เพื่อป้องกันไม่ให้ Service เสีย Resource ไปกับ Request ที่มีแนวโน้มล้มเหลว และลดโอกาสเกิด Cascading Failure

Circuit Breaker โดยทั่วไปจะมี 3 สถานะ

• Closed คือทำงานปกติ Request ถูกส่งไปยัง Dependency
• Open คือ Dependency มี Error หรือ Timeout เกิน Threshold ระบบหยุดเรียกชั่วคราวและ Fail Fast
• Half-open คือปล่อย Request ทดลองจำนวนเล็กน้อยเพื่อดูว่า Dependency กลับมาปกติหรือยัง

ลองดู Use Case ในระบบ Gym Application Payment Service ต้องเรียก Payment Gateway ภายนอก ถ้า Gateway เริ่ม Timeout ทุก Request จะรอจนหมดเวลา ทำให้ Thread, Connection Pool และ Worker ของ Payment Service ถูกใช้จนเต็ม

เมื่อมี Circuit Breaker หาก Timeout หรือ Error สูงเกิน Threshold ระบบจะเปิด Circuit แล้วตอบกลับเร็วขึ้น เช่น payment_temporarily_unavailable หรือให้ลูกค้าลองใหม่ภายหลัง แทนที่จะปล่อยให้ทุก Request ค้างรอ Gateway ที่กำลังมีปัญหา

ข้อดี

• Circuit Breaker ช่วยป้องกัน Cascading Failure โดยหยุดเรียก Dependency ที่กำลังมีปัญหา เพื่อไม่ให้ Service ต้นทางเสีย Resource โดยไม่จำเป็น
• ช่วยลดภาระของ Dependency ที่กำลังมีปัญหา เพื่อให้มีโอกาสกลับมาทำงานได้ตามปกติ
• ทำให้ระบบ Fail Fast และสามารถเลือก Fallback ได้ เช่น ใช้ข้อมูล Cache, แสดงสถานะชั่วคราว หรือปิด Feature บางส่วน

Trade-off

• ถ้ากำหนดเงื่อนไขให้ Circuit เปิดง่ายเกินไป ระบบอาจหยุดเรียก Dependency บ่อยเกินความจำเป็น ทั้งที่ Dependency ยังสามารถให้บริการได้อยู่
• ถ้ากำหนดเงื่อนไขให้ Circuit เปิดช้าเกินไป Service ต้นทางอาจยังส่ง Request ไปยัง Dependency ที่มีปัญหาต่อเนื่อง จน Resource ของตัวเองถูกใช้มากเกินไป
• ต้อง Monitoring สถานะ Circuit ให้ดี เพราะ Open Circuit คือสัญญาณว่าระบบกำลัง Degrade ไม่ใช่สถานะปกติ

Rate Limiting

Rate Limiting คือการจำกัดจำนวน Request ที่ Client, User, IP, API Key หรือ Service สามารถส่งเข้ามาได้ภายในช่วงเวลาที่กำหนด

เป้าหมายคือป้องกัน Abuse, Bot, Bug จาก Client, Traffic Spike และป้องกันไม่ให้ผู้ใช้บางกลุ่มใช้ Capacity มากเกินส่วนที่ควรได้

ลองดู Use Case ในระบบ Gym Application Endpoint ที่ควรถูก Rate Limit เช่น

• Login API เพื่อป้องกัน Brute Force
• Booking API เพื่อป้องกันการกดจองรัว ๆ ตอนเปิดคลาส
• Payment API เพื่อป้องกันการยิงซ้ำจาก Client ที่มี Bug
• Search API เพื่อป้องกัน Query ที่หนักเกินไป
• AI Assistant API เพื่อควบคุมต้นทุนของ Model

ข้อดี

• Rate Limiting ป้องกันระบบจาก Traffic ที่ไม่เหมาะสมก่อนที่ Request จะไปถึง Service ด้านหลัง
• ช่วยกระจายการใช้งานระบบให้เหมาะสม เพราะ Client หนึ่งไม่สามารถใช้ทรัพยากรของระบบมากเกินส่วนจนกระทบ Client อื่น
• ช่วยควบคุมต้นทุนของ Endpoint ที่มีค่าใช้จ่ายต่อการเรียกใช้งาน เช่น External Provider หรือ AI Model

Trade-off

• ถ้าตั้ง Limit ต่ำเกินไป ผู้ใช้ปกติอาจถูกปฏิเสธในช่วงใช้งานจริง เช่น ลูกค้ากด Refresh หลายครั้งตอนจองคลาส
• ถ้าตั้ง Limit สูงเกินไป Rate Limiter อาจไม่ช่วยตอนระบบเจอ Traffic Spike
• ในระบบ Distributed ต้องมี Store กลางหรือวิธี Sync Counter ที่ดี ไม่เช่นนั้น Client อาจหลบ Limit ได้โดยกระจาย Request ไปหลาย Server

Load Shedding

Load Shedding คือการตั้งใจปฏิเสธงานบางส่วนเมื่อระบบ Overload เพื่อรักษาให้ส่วนสำคัญของระบบยังทำงานได้ แทนที่จะพยายามรับทุก Request แล้วล่มทั้งระบบ

แนวคิดคือ Partial Availability ดีกว่า Total Failure ระบบที่ตอบสำเร็จ 80% ด้วย Latency ดี ยังมีประโยชน์กว่าระบบที่พยายามรับ 100% แล้ว Timeout ทั้งหมด

ลองดู Use Case ในระบบ Gym Application เวลา 18:00 น. มีลูกค้าจำนวนมากเข้ามาจองคลาสยอดนิยมพร้อมกัน ระบบอาจต้องจัดลำดับความสำคัญของงาน

งานสำคัญ

• Booking Request
• Payment Confirmation
• Check-in Request

งานอื่นๆ

• Analytics Event
• Recommendation Update
• Campaign Notification
• Admin Report ที่ไม่ได้ต้อง Real-time

เมื่อ CPU, Queue Length หรือ p95 Latency เกิน Threshold ระบบจะหยุดรับงานสำคัญต่ำชั่วคราว ลดคุณภาพของบาง Response หรือคืน HTTP 503 พร้อม Retry-After ให้ Client บางกลุ่ม

ข้อดี

• Load Shedding ช่วยให้ระบบไม่ล่มทั้งก้อนเมื่อ Load เกิน Capacity จริง
• ทำให้ทีมกำหนดได้ว่างานใดควรถูกปกป้องก่อน เช่น Payment และ Check-in ควรสำคัญกว่า Analytics
• ช่วยลด Retry Storm เพราะระบบตอบกลับเร็วและชัดเจนกว่าปล่อยให้ Request ค้างจน Timeout

Trade-off

• ผู้ใช้บางส่วนหรือ Feature บางส่วนจะได้รับผลกระทบโดยตั้งใจ จึงต้องออกแบบ Error Message, Retry Policy และ UX ให้ดี
• ถ้า Shedding ผิดจุด อาจทิ้งงานที่สำคัญหรือทำให้ข้อมูลขาด เช่น ทิ้ง Event ที่จำเป็นต่อ Audit
• ต้องวัด Load จากสัญญาณที่ถูกต้อง เช่น CPU, Memory, Queue Length, Error Rate, p95/p99 Latency ไม่ใช่ดูแค่ RPS เพราะ Request แต่ละแบบใช้ Resource ไม่เท่ากัน

Bloom Filter

Bloom Filter คือโครงสร้างข้อมูลที่ใช้ตรวจสอบอย่างรวดเร็วว่า Item หนึ่ง อาจอยู่ หรือ ไม่มีอยู่แน่นอน ใน Set

คำตอบของ Bloom Filter มี 2 แบบ

• Definitely not in set คือไม่มีแน่นอน
• Might be in set คืออาจมีอยู่ ต้องตรวจสอบต่อกับแหล่งข้อมูลจริง

Bloom Filter ไม่มี False Negative แต่มี False Positive ได้ หมายความว่าถ้ามันบอกว่าไม่มีคือไม่มีแน่ แต่ถ้าบอกว่าอาจมี อาจต้องไป Query Database เพื่อยืนยันอีกครั้ง

Bloom Filter มักใช้เพื่อลดจำนวน Query ที่ไม่จำเป็น โดยตรวจสอบก่อนว่า Key หรือ Item นั้นมีโอกาสอยู่ในระบบหรือไม่

ลองดู Use Case ในระบบ Gym Application ระบบมี API สำหรับตรวจรหัส Promotion หรือรหัส Invitation จำนวนมาก ถ้าผู้ใช้หรือ Bot เดาสุ่มรหัสที่ไม่มีอยู่จริง ระบบอาจต้อง Query Database จำนวนมหาศาลโดยไม่จำเป็น

เราสามารถใส่รหัส Promotion ที่มีอยู่จริงเข้า Bloom Filter ก่อน แล้ว Flow เป็นแบบนี้

• Client ส่ง promotion_code เข้ามา
• API ตรวจ Bloom Filter
• ถ้า Bloom Filter บอกว่าไม่มีแน่นอน ตอบกลับได้ทันทีว่า code ไม่ถูกต้อง
• ถ้า Bloom Filter บอกว่าอาจมี ค่อย Query Database เพื่อตรวจสอบสถานะจริง เช่น หมดอายุหรือถูกใช้ไปแล้วหรือยัง

ข้อดี

• Bloom Filter ใช้ Memory น้อยมากเมื่อเทียบกับการเก็บ Set เต็ม ๆ
• ช่วยลด Query ที่ไม่จำเป็นต่อ Database หรือ Storage ได้ดี โดยเฉพาะกรณีมี Request จำนวนมากที่อ้างอิง Key ที่ไม่มีอยู่จริง
• เหมาะกับงานอย่างตรวจ URL ที่เคย Crawl แล้ว, ตรวจ Key ที่อาจอยู่ใน SSTable หรือทำ Negative Lookup ก่อนเข้า Database

Trade-off

• Bloom Filter มี False Positive จึงไม่ควรใช้ตัดสินใจเรื่องสำคัญเพียงลำพัง เช่น ห้ามใช้เพื่อบอกว่าลูกค้ามีสิทธิ์เข้ายิมโดยไม่ตรวจ Database ต่อ
• ถ้าต้องลบข้อมูลออกจาก Set ต้องใช้โครงสร้างแบบพิเศษ เช่น Counting Bloom Filter เพราะ Bloom Filter แบบพื้นฐานลบ Item เดี่ยวได้ยาก
• ต้องเลือกขนาด Filter และจำนวน Hash Function ให้เหมาะสม ไม่เช่นนั้น False Positive Rate จะสูงเกินไปจนลดประโยชน์ของมัน

Embedding

Embedding คือการแปลงข้อมูล เช่น ข้อความ รูปภาพ หรือเอกสาร ให้กลายเป็น Vector ของตัวเลข เพื่อให้ระบบคอมพิวเตอร์เปรียบเทียบความใกล้เคียงเชิงความหมายได้

ลองดู Use Case ในระบบ Gym Application ระบบ Search แบบ Keyword ธรรมดาอาจค้นหาได้เฉพาะคำที่ตรงกัน เช่น ผู้ใช้ค้นคำว่า "freeze membership" แต่เอกสารในระบบเขียนว่า "พักสมาชิกชั่วคราว" Search แบบ Keyword อาจหาไม่เจอ

ถ้าใช้ Embedding Flow จะเป็นแบบนี้

• แบ่งเอกสารนโยบายและ FAQ เป็น Chunk
• แปลงแต่ละ Chunk เป็น Embedding
• เก็บ Vector ลง Vector Database
• เมื่อผู้ใช้ค้นหา แปลง Query เป็น Embedding
• หา Chunk ที่ Vector ใกล้กับ Query มากที่สุด
• แสดงผลลัพธ์หรือส่งต่อให้ระบบ AI Assistant

ข้อดี

• Embedding ช่วยให้ระบบค้นหาจากความหมาย ไม่ใช่แค่คำที่ตรงกัน
• เหมาะกับ Semantic Search, Recommendation, Similar Document Search, Duplicate Detection และการจัดกลุ่มเนื้อหา
• ช่วยให้ข้อมูลหลายภาษาเชื่อมกันได้ดีขึ้น ถ้า Model รองรับ Multilingual Embedding

Trade-off

• Embedding ไม่ได้เข้าใจความถูกต้องของข้อมูลเสมอไป มันแค่บอกความใกล้เคียงเชิงความหมาย จึงยังต้องมี Permission Filter, Metadata Filter และ Business Rule ประกอบ
• ต้องดูแลเรื่อง Chunking, Vector Database, Re-indexing และ Model Version เพราะถ้าเปลี่ยน Model อาจต้องสร้าง Embedding ใหม่ทั้งหมด
• การค้นหาแบบ Vector อาจได้ผลลัพธ์ที่ดูเกี่ยวข้องแต่ไม่ใช่คำตอบที่ถูกต้องที่สุด จึงควรมี Ranking หรือ Validation เพิ่มเติมในงานสำคัญ

RAG (Retrieval-Augmented Generation)

RAG หรือ Retrieval-Augmented Generation คือ Architecture ที่ช่วยให้ Language Model ตอบคำถามโดยอ้างอิงข้อมูลจากแหล่งความรู้ภายนอก แทนที่จะตอบจากความรู้ที่อยู่ใน Model เพียงอย่างเดียว

แนวคิดคือไม่ปล่อยให้ Model ตอบจากความรู้ที่ฝังอยู่ใน Parameter อย่างเดียว แต่ให้ระบบ Retrieve เอกสารที่เกี่ยวข้องก่อน แล้วส่งเอกสารเหล่านั้นไปเป็นบริบทให้ Model ใช้สร้างคำตอบ

ลองดู Use Case ในระบบ Gym Application ทีม Support หรือ Admin ถาม AI Assistant ว่า

• "สมาชิก Premium พักสมาชิกได้กี่วัน"
• "ถ้าลูกค้าจ่ายเงินแล้วแต่ Booking ไม่สำเร็จ ต้องทำอย่างไร"
• "เอกสารสัญญาสมาชิกอยู่ที่ไหน"
• "คลาสไหนมีเงื่อนไขยกเลิกล่วงหน้า"

Flow ของ RAG จะเป็นแบบนี้

• User ส่งคำถาม
• ในกรณีที่ใช้ Semantic Search ระบบจะแปลงคำถามเป็น Embedding
• แล้วค้นเอกสารที่เกี่ยวข้องจาก Vector Database เช่น FAQ, Policy, Contract Template, Internal Runbook
• ส่งคำถามพร้อมเอกสารที่ค้นได้ให้ Language Model
• Model สร้างคำตอบจาก Context ที่ได้รับ
• ระบบแสดงคำตอบพร้อมแหล่งอ้างอิงหรือ Link ไปยังเอกสารต้นทาง

ข้อดี

• RAG ช่วยให้คำตอบอิงกับข้อมูลของระบบจริงมากขึ้น และสามารถอัปเดตความรู้ได้โดยอัปเดตเอกสารหรือ Index โดยไม่ต้อง Train Model ใหม่ทุกครั้ง
• เหมาะกับระบบที่มี Knowledge Base, Policy, FAQ, Internal Document หรือ Product Catalog จำนวนมาก
• ช่วยลด Hallucination ได้เมื่อ Retrieval ดีและ Prompt บังคับให้ตอบจาก Context เท่านั้น

Trade-off

• คุณภาพของ RAG ขึ้นอยู่กับคุณภาพของ Retrieval ถ้าค้นเอกสารผิดหรือ Chunk ไม่ดี Model ก็อาจตอบผิดจากบริบทที่ผิด
• ต้องจัดการสิทธิ์การเข้าถึงข้อมูลให้เข้มงวด เช่น Admin เห็นเอกสารภายในได้ แต่ลูกค้าทั่วไปไม่ควรเห็น Runbook หรือข้อมูลส่วนตัวของสมาชิกคนอื่น
  ระบบซับซ้อนกว่า Chatbot ปกติ เพราะต้องดูแล Pipeline ตั้งแต่ Ingestion, Chunking, Embedding, Indexing, Retrieval, Prompting, Evaluation และ Monitoring

MCP (Model Context Protocol)

MCP หรือ Model Context Protocol คือมาตรฐานเปิดสำหรับเชื่อม AI Application เข้ากับข้อมูลและ Tool จากระบบภายนอกผ่านรูปแบบการสื่อสารที่เป็นมาตรฐานเดียวกัน

ระบบภายนอกเหล่านี้อาจเป็น Files, Database, API หรือ Service ต่าง ๆ โดย MCP Server จะกำหนดความสามารถที่ AI สามารถเข้าถึงได้ เช่น อ่านข้อมูล เรียก Function หรือใช้ Prompt Template

ถ้า RAG เน้นการค้นข้อมูลจาก Knowledge Base เพื่อนำมาเป็น Context ให้ Language Model ตอบคำถาม MCP จะกว้างกว่า เพราะนอกจากอ่านข้อมูลแล้ว AI ยังสามารถเรียก Tool เพื่อทำงานกับระบบภายนอกได้ เช่น

• ค้นข้อมูลสมาชิก
• ดูตารางคลาส
• อ่านข้อมูลการจอง
• เรียก API
• สร้าง Support Ticket
• อัปเดตข้อมูลตามสิทธิ์ที่กำหนด

โครงสร้างหลักของ MCP มี 3 ส่วน

• Host คือ AI Application ที่ผู้ใช้ใช้งาน เช่น Chat Application, IDE หรือ AI Assistant
• Client คือ Component ภายใน Host ที่ใช้สื่อสารกับ MCP Server
• Server คือระบบที่เปิดความสามารถให้ Client ใช้งาน เช่น Tools, Resources และ Prompts

ลองดู Use Case ในระบบ Gym Application ถ้าเรามี AI Assistant สำหรับทีม Support ระบบอาจต้องเชื่อมต่อกับหลาย Service เช่น

• อ่าน Policy การพักสมาชิกจาก Knowledge Base
• ค้นสถานะสมาชิกจาก Member Service
• ดูประวัติการจองจาก Booking Service
• สร้าง Support Ticket เมื่อพบปัญหาที่ต้องให้เจ้าหน้าที่ตรวจสอบ
• อ่านข้อมูลเอกสารสัญญาที่เกี่ยวข้อง

ถ้าไม่มี MCP เราต้องเขียน Integration ระหว่าง AI Assistant กับแต่ละระบบแยกกัน เช่น เขียนวิธีเชื่อม Database แบบหนึ่ง เชื่อม Ticket System อีกแบบหนึ่ง และเชื่อม Internal API อีกแบบหนึ่ง

เมื่อใช้ MCP เราสามารถกำหนดความสามารถเหล่านี้ผ่าน MCP Server แล้วให้ AI Application เรียกใช้งานผ่าน MCP Client ด้วยรูปแบบเดียวกัน

Flow จะเป็นแบบนี้

• Support ส่งคำถามให้ AI Assistant
• AI Assistant เชื่อมต่อกับ MCP Server ผ่าน MCP Client
• MCP Server เปิด Tool เช่น search_member, get_booking_history และ create_support_ticket
• AI Assistant เลือกเรียก Tool ที่เหมาะสม
• MCP Server ดึงข้อมูลหรือทำ Action กับระบบจริง
• ผลลัพธ์ถูกส่งกลับมาให้ AI Assistant ใช้สร้างคำตอบ

ข้อดี

• MCP ช่วยให้การเชื่อม AI Application กับ Tool และข้อมูลภายนอกมีรูปแบบมาตรฐานมากขึ้น
• AI Application ไม่จำเป็นต้องรู้รายละเอียดภายในของ Database หรือ Service แต่เรียกผ่าน Tool หรือ Resource ที่ MCP Server กำหนดไว้
• สามารถนำ MCP Server เดิมไปใช้กับ AI Application ที่รองรับ MCP ได้หลายตัว
• เหมาะกับ Agentic Workflow ที่ AI ต้องทั้งอ่านข้อมูลและทำ Action กับระบบภายนอก

Trade-off

• MCP ทำให้ AI สามารถเข้าถึงข้อมูลและ Tool ภายนอกได้มากขึ้น จึงต้องออกแบบ Authentication, Authorization และ Audit Log ให้เหมาะสม
• Tool ควรถูกออกแบบให้มีขอบเขตชัดเจน เช่น เปิด search_member แทนการให้ AI Query Database ได้อย่างอิสระ
• Action ที่มีผลกระทบสูง เช่น ยกเลิกสมาชิก คืนเงิน หรือแก้ไขข้อมูลสำคัญ อาจต้องมีขั้นตอน Confirmation หรือ Human Approval
• ต้องดูแล Compatibility เมื่อมีการเปลี่ยน Schema หรือความสามารถของ MCP Server

สรุป

Communication ในรูปแบบต่างๆ เป็นพื้นฐานสำคัญของ System Design เมื่อระบบเริ่มมีหลาย Service เพราะแต่ละส่วนต้องสื่อสารกันทั้งแบบ Synchronous, Asynchronous, Real-time และ Event-driven

SOAP, REST, gRPC, GraphQL และ Webhook ใช้สำหรับการสื่อสารระหว่างระบบ ส่วน Message Queue, Message Broker, Pub/Sub, DLQ และ Backpressure ช่วยจัดการงานและ Event แบบ Asynchronous

WebSocket และ SSE เหมาะกับ Real-time Communication ขณะที่ Circuit Breaker, Rate Limiting และ Load Shedding ช่วยป้องกันระบบเมื่อเกิดปัญหาหรือมี Load สูงเกินไป

ส่วน Bloom Filter, Embedding, RAG และ MCP เป็นแนวคิดที่ช่วยด้าน Search และ AI

Refs

• System Design Interview – An insider's guide
• 50 System Design Concepts Explained Simply [2026 Edition]