Event Sourcing ในวงการ FinTech: คือความงามทางสถาปัตยกรรม หรือความซับซ้อนที่ไม่จำเป็น?

ในโลกของเทคโนโลยีการเงิน มีรูปแบบสถาปัตยกรรมไม่กี่อย่างที่ก่อให้เกิดการถกเถียงอย่างร้อนแรงได้เท่ากับ Event Sourcing ที่ทำงานคู่กับ CQRS กรณีศึกษาล่าสุดจากโครงการที่ปรึกษาที่นำรูปแบบเหล่านี้ไปใช้กับแพลตฟอร์มซื้อขายหลักทรัพย์ ได้จุดประกายการอภิปรายอย่างเข้มข้นในหมู่นักพัฒนาและสถาปนิกซอฟต์แวร์ ในขณะที่ผู้เขียนต้นฉบับยกย่อง Event Sourcing ในฐานะโซลูชันสำหรับการตรวจสอบย้อนกลับและประสิทธิภาพ แต่ชุมชนนักพัฒนายังคงแตกออกเป็นสองฝ่ายชัดเจนว่าวิธีนี้แสดงถึงความก้าวหน้าทางสถาปัตยกรรมหรือเป็นเพียงความซับซ้อนที่ไม่จำเป็น

ประเด็นถกเถียงหลัก: การออกแบบที่เกินความจำเป็นสำหรับข้อกำหนดที่เรียบง่าย?

การโต้แย้งหลักวนเวียนอยู่ที่ว่า Event Sourcing เป็นโซลูชันที่เหมาะสมสำหรับข้อกำหนดทางการเงินที่ดูเหมือนจะตรงไปตรงมาหรือไม่ ผู้วิจารณ์แย้งว่าความต้องการพื้นฐาน—การแสดงยอดเงินในบัญชี ณ ช่วงเวลาใดๆ เพื่อให้เป็นไปตามข้อกำหนดทางกฎระเบียบ—สามารถตอบสนองได้ด้วยวิธีการที่เรียบง่ายกว่าและผ่านการทดสอบมาแล้ว ตารางชั่วคราว (Temporal tables) ในฐานข้อมูลสมัยใหม่หรือบันทึกการตรวจสอบ (audit logs) ที่มีโครงสร้างดี สามารถให้ความสามารถในการมองเห็นประวัติศาสตร์ที่จำเป็นได้ โดยไม่ต้องมีความซับซ้อนของความสามารถในการเล่นซ้ำเหตุการณ์ (event replay) เต็มรูปแบบ

ผู้แสดงความคิดเห็นหนึ่งคนสรุปความเคลือบแคลงไว้ได้อย่างคมชัด: Event Sourcing ดูเหมือนจะเป็นการยิงปืนนัดเดียวไปนกหลายตัวเกินไปสำหรับปัญหาที่ระบุ ความต้องการหลักนั้นง่ายๆ คือ 'แสดงยอดเงินในบัญชี ณ ช่วงเวลาใดๆ' เพื่อการปฏิบัติตามกฎระเบียบ ความรู้สึกนี้สะท้อนไปทั่วการอภิปราย的大部分 โดยนักพัฒนาตั้งคำถามว่าความซับซ้อนทางสถาปัตยกรรมนี้มีความสมเหตุสมผลจากข้อกำหนดทางธุรกิจที่แท้จริง หรือเป็นเพียงความชอบทางเทคนิค

ปริศนาความไม่เปลี่ยนแปลง: คุณเปลี่ยนแปลงอดีตได้จริงๆ หรือ?

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

ชุมชนชี้ให้เห็นถึงความแตกต่างระหว่างการแก้ไขข้อผิดพลาดผ่านเหตุการณ์ชดเชย (compensating events) ใหม่ กับการไปแก้ไขบันทึกทางประวัติศาสตร์จริงๆ อย่างรวดเร็ว ดังที่นักพัฒนาหนึ่งอธิบายชัดเจน เหตุการณ์นั้นไม่สามารถเปลี่ยนแปลงได้ (Immutable) หากมีเหตุการณ์หนึ่งผิดพลาด คุณก็จะโพสต์เหตุการณ์ใหม่ที่มีการแก้ไข จากนั้น ค่อยสร้างสถานะของแอปพลิเคชันใหม่ วิธีการนี้รักษาความสมบูรณ์ของการตรวจสอบไว้ ในขณะที่ยังอนุญาตให้มีการแก้ไขได้ แม้ว่ามันจะนำมาซึ่งความซับซ้อนของตัวเองในการทำให้แน่ใจว่าเหตุการณ์ที่ตามมายังคงมีความถูกต้อง

การแลกเปลี่ยนด้านประสิทธิภาพ: การแก้ปัญหาและการสร้างปัญหาใหม่

เรื่องเล่าเกี่ยวกับประสิทธิภาพเผยให้เห็นความขัดแย้งที่น่าสนใจ ในขณะที่ Event Sourcing ถูกเลือกมาเพื่อแก้ไขข้อกังวลด้านประสิทธิภาพ ผู้แสดงความคิดเห็นตั้งข้อสังเกตว่าการนำไปใช้งานกลับสร้างความท้าทายด้านประสิทธิภาพรูปแบบใหม่ การคำนวณยอดเงินในตอนแรกใช้เวลา 2-5 วินาที ซึ่งจำเป็นต้องมีกลยุทธ์สแนปชอต (snapshot) ที่ซับซ้อนเพื่อลดเวลาลงเหลือ 50-200 มิลลิวินาที ในขณะเดียวกัน ผู้วิจารณ์เสนอว่าฐานข้อมูลแบบดั้งเดิมที่ได้รับการปรับแต่งอย่างดีสามารถตอบสนองได้ในหน่วยมิลลิวินาทีหลักเดียวได้ โดยไม่มีโอเวอร์เฮดของระบบแบบกระจาย (distributed systems)

การแยกฐานข้อมูลสำหรับการอ่านและเขียน—ซึ่งเป็นหลักการพื้นฐานของ CQRS—ก็ถูกตั้งคำถามเช่นเดียวกัน เมื่อพิจารณาว่า PostgreSQL ถูกใช้งานอยู่แล้วพร้อมกับการรับประกันความถูกต้องแม่นยำแบบ ACID ที่แข็งแกร่ง การนำ MongoDB มาใช้สำหรับการอ่านจึงเพิ่มความสม่ำเสมอแบบ eventual consistency ในที่ที่ความสม่ำเสมอแบบทันที (immediate consistency) อาจจะดีกว่า โอเวอร์เฮดของการประสานงานระหว่างระบบกลายเป็นข้อพิจารณาด้านประสิทธิภาพรูปแบบใหม่ แทนที่จะเป็นการเพิ่มประสิทธิภาพล้วนๆ

ความท้าทายทั่วไปในการนำ Event Sourcing ไปใช้งาน

• ประสิทธิภาพ: การคำนวณยอดคงเหลือเริ่มต้นใช้เวลา 2-5 วินาที จำเป็นต้องมีการปรับปรุงด้วย snapshot
• ความสอดคล้องของข้อมูล: การแยกฐานข้อมูลสำหรับอ่านและเขียนทำให้เกิดปัญหา eventual consistency
• การปฏิบัติตาม GDPR: เหตุการณ์ที่ไม่สามารถเปลี่ยนแปลงได้ขัดแย้งกับสิทธิในการถูกลืม
• ความซับซ้อนของระบบ: ต้องใช้ message brokers หลายตัว event processors และ read models
• ภาระงานในการพัฒนา: ต้องใช้เวลามากในการทำงานเบื้องต้นก่อนที่จะส่งมอบคุณค่าทางธุรกิจ
• ความซับซ้อนในการดำเนินงาน: การติดตามและบำรุงรักษากระบวนการเหตุการณ์แบบกระจาย

เมื่อไหร่ที่ Event Sourcing สมเหตุสมผลจริงๆ

แม้จะมีการวิจารณ์ ผู้แสดงความคิดเห็นหลายคนก็ยอมรับกรณีใช้ที่ชอบธรรมสำหรับ Event Sourcing ในระบบการเงิน รูปแบบนี้จะเปล่งประกายเมื่อคุณต้องการความสามารถในการเล่นประวัติศาสตร์ซ้ำผ่านกฎธุรกิจที่แตกต่างกันจริงๆ หรือเมื่อต้องแก้ไขข้อผิดพลาดในการตีความเชิงระบบ ดังที่นักพัฒนาหนึ่งระบุไว้ หากในช่วงเวลาหนึ่งคุณมีบั๊กในโค้ดของคุณ การมี event sourcing ทำให้คุณสามารถแก้ไขบั๊กนั้นและเล่นเหตุการณ์ทั้งหมดซ้ำอีกครั้งเพื่อแก้ไขภาพฉาย (projections) ปัจจุบันของสถานะได้

การอภิปรายยังเน้นย้ำว่า Event Sourcing สอดคล้องตามธรรมชาติกับแนวคิดทางการเงิน เช่น การบัญชีคู่ (double-entry accounting) ซึ่งบัญชีแยกประเภทของธุรกรรมมีความสำคัญโดยพื้นฐานมากกว่าการคำนวณยอดเงินใดๆ เพียงครั้งเดียว อย่างไรก็ตาม ดังที่ผู้แสดงความคิดเห็นหลายคนชี้ให้เห็น แม้แต่ระบบบัญชีแบบดั้งเดิมก็ใช้ยอดรวมสะสม (running totals) แทนที่จะคำนวณทุกอย่างใหม่ตั้งแต่เริ่มต้นสำหรับการดำเนินงานประจำวัน

ความเป็นจริงในการนำไปใช้: ความยุ่งยากและการสะสมความซับซ้อน

ความคิดเห็นจำนวนมากมุ่งเน้นไปที่ความท้าทายในการนำไปปฏิบัติจริง Event Sourcing ต้องการการลงทุนล่วงหน้าอย่างมากในโครงสร้างพื้นฐาน การประมวลผลข้อความ และการจัดการข้อผิดพลาด นักพัฒนาหนึ่งคนเรียกมันว่าเป็นสถาปัตยกรรมที่เจ๋งมากและสมเหตุสมผลในทางทฤษฎี แต่ความยุ่งยากที่ต้องทำก่อนจะลงมือImplement มันมีอย่างน้อยมากกว่าการออกแบบอื่นๆ ถึงสิบเท่า

ความซับซ้อนนี้ขยายไปถึงกฎระเบียบด้านความเป็นส่วนตัวของข้อมูล เช่น GDPR ซึ่งสิทธิในการถูกลืม (right to be forgotten) ขัดแย้งกับธรรมชาติที่ไม่เปลี่ยนแปลงของที่เก็บเหตุการณ์ (event stores) มีการพูดถึงโซลูชันเชิงสร้างสรรค์ เช่น การเข้ารหัสข้อมูลส่วนบุคคล (PII) ด้วยคีย์ที่ลบได้ แต่สิ่งเหล่านี้ก็เพิ่มเลเยอร์ของความซับซ้อนอีกชั้นหนึ่งให้กับระบบที่ซับซ้อนอยู่แล้ว

แนวทางอื่นที่อาจจะเพียงพอแล้ว

การอภิปรายในชุมชนเผยให้เห็นสถาปัตยกรรมทางเลือกหลายอย่างที่สามารถตอบสนองข้อกำหนดเดียวกันได้ด้วยความซับซ้อนที่น้อยกว่า ฐานข้อมูลสมัยใหม่ที่มีบันทึกล่วงหน้า (write-ahead logs) นั้นให้ที่เก็บเหตุการณ์ที่ไม่เปลี่ยนแปลงในระดับโครงสร้างพื้นฐานได้อย่างมีประสิทธิภาพ ที่เก็บข้อมูลแบบมีเวอร์ชันพร้อมกับการควบคุมความขัดแย้งแบบมองโลกในแง่ดี (optimistic concurrency control) สามารถให้บันทึกการตรวจสอบย้อนกลับได้ ในขณะที่ยังคงลักษณะการดำเนินงานที่เรียบง่ายกว่า

ผู้แสดงความคิดเห็นหลายคนแนะนำว่าระบบดั้งเดิมที่ออกแบบมาอย่างดี พร้อมกับการบันทึกการตรวจสอบ (audit logging) ที่เหมาะสมและความสามารถในการสอบถามข้อมูลชั่วคราว (temporal query) สามารถตอบสนองข้อกำหนดทางกฎระเบียบได้ ในขณะที่เข้าใจ บำรุงรักษา และดำเนินการได้ง่ายกว่า ข้อสรุปที่สำคัญคือการจับคู่ความซับซ้อนของสถาปัตยกรรมกับข้อกำหนดทางธุรกิจที่แท้จริง แทนที่จะเป็นความเป็นไปได้ในทางทฤษฎี

การเปรียบเทียบ Event Sourcing กับแนวทางแบบดั้งเดิม

บทสรุป: เลือกใช้เครื่องมือที่เหมาะสมกับงาน

การอภิปรายอันร้อนแรงรอบๆ เรื่อง Event Sourcing ใน FinTech เผยให้เห็นความจริงที่กว้างขึ้นเกี่ยวกับสถาปัตยกรรมซอฟต์แวร์: ไม่มีกระสุนวิเศษ มีเพียงการแลกเปลี่ยนเท่านั้น Event Sourcing ร่วมกับ CQRS ให้ความสามารถอันทรงพลังสำหรับบางสถานการณ์—โดยเฉพาะเมื่อคุณต้องการตีความประวัติศาสตร์ใหม่จริงๆ หรือรักษารูปแบบการอ่านที่สอดคล้องกันหลายรูปแบบ อย่างไรก็ตาม สำหรับแอปพลิเคชันทางการเงินจำนวนมาก แนวทางที่เรียบง่ายกว่าที่ใช้ฐานข้อมูลชั่วคราวหรือบันทึกการตรวจสอบอาจให้ฟังก์ชันการทำงานที่เพียงพอด้วยความซับซ้อนที่น้อยลงอย่างมาก

ดังที่ฉันทามติของชุมชนแนะนำ การตัดสินใจใช้ Event Sourcing ควรถูกขับเคลื่อนโดยข้อกำหนดเฉพาะที่เป็นรูปธรรม แทนที่จะเป็นแฟชั่นทางสถาปัตยกรรม เมื่อข้อกำหนดการตรวจสอบตามกฎหมายต้องการความสามารถในการเล่นประวัติศาสตร์ซ้ำอย่างสมบูรณ์ Event Sourcing ก็กลายเป็นสิ่งจำเป็น สำหรับกรณีอื่นๆ ส่วนใหญ่ นักพัฒนาอาจจะได้รับบริการที่ดีกว่าด้วยการเลือกใช้เครื่องมือที่เรียบง่ายกว่าจากกล่องเครื่องมือทางสถาปัตยกรรมของพวกเขา

อ้างอิง: Event Sourcing, CQRS and Micro Services: Real FinTech Example from my Consulting Career