ในโลกการเงินที่หมุนเร็ว… ข้อมูลของคุณยังถูกส่งแบบ “จดหมาย” อยู่หรือเปล่า?

Batch vs Event-Driven Architecture (ฉบับเข้าใจง่ายแบบ KSN)

ถ้าคุณทำงานสาย Product / Dev / Data ในโลกการเงิน คุณน่าจะเคยเจอโมเมนต์นี้ ข้อมูลมีนะ… แต่ “ยังไม่มา” สถานะธุรกรรมเกิดแล้ว… แต่ dashboard ยังไม่ขยับ Fraud เกิดไปแล้ว… แต่ alert ดันมาทีหลัง คำถามคือ ระบบของคุณ “เห็นความจริง” ช้าไปกี่นาที? และในบางเคส “กี่นาที” นั่นแหละที่แพงที่สุด วันนี้เราจะอธิบายสองแนวทางหลักในการส่ง/ประมวลผลข้อมูลให้เข้าใจง่าย พร้อมมุมคิดว่า เมื่อไหร่ควรใช้แบบไหน

สรุปสั้น ๆ ก่อน • Batch = รวบรวมก่อน ค่อยประมวลผลทีเดียวเป็นรอบ • Event-Driven = มีเหตุการณ์ปุ๊บ ส่งปั๊บ ประมวลผลต่อเนื่อง • ในโลกการเงิน บางเหตุการณ์ “รอไม่ได้” เพราะช้า = เสียโอกาส/เพิ่มความเสี่ยง

เปรียบเทียบแบบเห็นภาพ จดหมาย vs LINE

1. Batch Processing (แบบเดิม) = ส่งจดหมาย นึกภาพว่าเราต้องส่งข้อมูลจำนวนมาก แต่ส่งทีเดียวตอนสิ้นวัน เหมือนการส่งจดหมายที่ต้อง รอรวบรวม รอรถมารับ รอคัดแยก แล้วค่อยส่งไปปลายทาง

ข้อดีของ Batch

• เหมาะกับงานที่ไม่ต้อง real-time (เช่น รายงานสิ้นวัน/ETL บางประเภท) • จัดการง่ายในมุม “ควบคุมรอบเวลา” • บางระบบ legacy รองรับได้ดี

ข้อจำกัดของ Batch

• มองสถานะช้า “ตามรอบ” • ถ้าเกิดความผิดพลาดใน batch หนึ่งรอบ อาจกระทบเป็นก้อนใหญ่ • ไม่เหมาะกับ use case ที่ต้องตอบสนองทันที

2) Event-Driven Architecture (แบบใหม่) = ส่งข้อความใน LINE

เหตุการณ์เกิดปุ๊บ…ข้อมูลไหลปั๊บ แต่ละ transaction หรือ event ถูกส่งต่อทันที เพื่อให้ระบบปลายทางประมวลผลต่อเนื่อง

ข้อดีของ Event-Driven

• เห็นสัญญาณเร็วขึ้น (real-time visibility) • ตอบสนองเร็วขึ้น (real-time reaction) • แยกส่วนระบบได้ดีขึ้น (decoupling) ทำให้ต่อยอด use case ง่าย

ข้อจำกัดที่ต้องคิดให้ครบ

• ออกแบบยากกว่า (ต้องคิดเรื่อง ordering, retries, idempotency etc.) • Observability สำคัญมาก (ไม่งั้นจะ “ไหล” แต่ตามรอยไม่เจอ) • ต้องมี discipline เรื่อง data contracts และ quality gates

แล้วทำไมโลกการเงินถึงชอบ Event-Driven?

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

Event-Driven ช่วยให้

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

พูดง่าย ๆ คือ ข้อมูลที่สดใหม่ คือเชื้อเพลิงของระบบ real-time

มุมมองจาก Krungsri Nimble: “Real-time” ต้องมาพร้อม “Control”

เวลาเราพูดถึง real-time ใน Banking Tech เรามองว่ามันไม่ใช่แค่ “ทำให้เร็ว” แต่คือ “ทำให้เร็วแบบคุมได้” เพราะเร็วอย่างเดียวไม่พอ ถ้า…ข้อมูลผิด (integrity) ตามรอยไม่ได้ (traceability) หรือสเกลไม่ไหว (scalability) ดังนั้นการขยับจาก Batch → Event-Driven มักเป็นมากกว่าการเลือกเทคโนโลยี แต่มันคือ การออกแบบระบบ + วิธีทำงานของทีมให้พร้อมกับโลกที่ทุกอย่างไหลตลอดเวลา

ชวนคิดท้ายบท

ในมุมมองของคุณ… ธุรกรรมแบบไหนที่ “รอไม่ได้” และต้องเป็น Real-time เท่านั้น? โอนเงิน? แลกพอยท์? ตรวจจับ fraud? อนุมัติสินเชื่อ? หรือการแจ้งเตือนบางอย่างที่ถ้าช้าไป 10 นาที ก็ไม่ทันแล้ว? คอมเมนต์มาแชร์กันหน่อย🙌 อยากรู้ว่าของแต่ละทีม “event ที่ต้องแก้ทันที” คืออะไร

ถ้าชอบบทความแนวนี้ กด Follow Krungsri Nimble ไว้ เดี๋ยวเราเอาเรื่อง Architecture ที่ “ใช้ได้จริง” มาเล่าอีกเรื่อย ๆ