Integrating EDA with Legacy systems

Legacy systems ระบบที่อยู่คู่กับองค์กร อาจจะเป็นฟันเฟืองตัวเล็กๆ ที่เรียกว่า monolithic applications ต่อกับ relational database หนึ่งในสมาชิกที่ทำให้องค์กรผ่านยุคของการอยู่รอด ดิ้นรน และเดินทางมาจนถึงยุคของ organizational culture จุดที่เราต้องเริ่มแข่งขันให้ทันคู่แข่ง มองหานวัตกรรม เทคโนโลยีที่ช่วยผลักดันให้องค์กรไปถึง goals

จากหนังสือ Building event-driven microservices ได้พูดถึงวิธีที่เราสามารถ integrate ข้อมูลกับ legacy systems โดยแนวคิดนี้เรียกว่า data liberation

Data Liberation

องค์กรส่วนใหญ่มี applications มากกว่า 1 ที่ on production ไม่ใช่เรื่องแปลกเวลาที่มี new project มักจะมี use cases ที่ต้องการข้อมูลจาก applications เหล่านั่น Data Liberation คือ migration strategy เพื่อให้เราสามารถ get data จาก legacy systems และนำข้อมูลไปใช้กับ Event-driven architecture (EDA) จากหนังสืออธิบายไว้ 3 Patterns ได้แก่ query based, log-based และ outbox table

Query-Based Data Liberation

Query-Based คือ data extraction จะเป็นเพิ่ม API ที่ application layer หรือ run คำสั่ง SQL เพื่อ query ข้อมูลจาก database โดยตัวที่ trigger การทำงานจะเป็น periodic task ตั้งเวลาเป็นช่วงๆ ตามความปรารถนาของนายท่าน เมื่อได้ result objects จะนำข้อมูลที่ได้ publish ไปที่ event bus

Pros:

• Customizability: client จัดการ query operation ดังนั้นเราสามารถกำหนดเงื่อนไขการดึงข้อมูลไม่ว่าจะเป็น table a + table b หรือสนใจเฉพาะ create_at ก็ว่ากันไป
• Independent polling periods: บางองค์กรมีขนาดข้อมูลมหาศาล วิธีการนี้ช่วย save resources เพราะสามารถกำหนดช่วงเวลา ความถี่ในการ query ข้อมูลได้

Cons:

• Required updated-at timestamp: table ที่เก็บข้อมูลต้องมี column updated-at เพื่อใช้สำหรับตรวจสอบ last update ของข้อมูล
• Untraceable hard deletions: hard deletions คือการลบข้อมูลออกจาก table ทำให้เมื่อดึงข้อมูลจะไม่แสดงใน query results ดังนั้นวิธีนี้จึงรองรับแค่การลบข้อมูลแบบ flag-based soft deletions คือการกำหนด is_deleted ใน column เป็นค่า boolean (true/false)
• Intermittent capture: data จะ synced ไปยัง event stream ในช่วง polling intervals เท่านั่น

Liberating Data Using Change-Data Capture Logs

ใน database จะมีสิ่งเล็กๆ ที่เรียกว่า data store logs (binary logs in MySQL, write-ahead logs for PostgresSQL, MongoDB’s op log) แนวคิดของ Change-Data Capture (CDC) คือการอ่านข้อมูลจาก logs เราจะ subscribe table ที่สนใจ เมื่อมี create, delete หรือ update จะเกิด log events ของ data changes เราจะนำข้อมูลชุดนี้ส่งต่อไปยัง event bus

Pros:

• Delete tracking: เมื่อมีการลบข้อมูลแบบ hard deletions หรือ soft deletions จะมีเก็บไว้ที่ data store logs
• Near real-time: เมื่อ data store logs เขียนสำเร็จ เราจะได้ log event ของ data change s แทบจะทันที
• Minimal effect on database performance: เนื่องจากเป็นอ่านข้อมูลจาก data store logs จึงมีผลกระทบกับ database performance น้อยกว่าวิธี query-based ที่ดึงข้อมูลจาก database ตรงๆ

Cons:

• Requires access to transaction logs: ต้องการสิทธ์ในการเข้าถึงใน low level ของ database ต้องระวังเรื่อง sensitive data และจัดการสิทธิ์ในการเห็นข้อมูล
• Implementation complexity varies across DBMS: วิธี configs, output schema หรือ tools ที่ใช้จะขึ้นอยู่ประเภทของ database

Liberating Data Using Outbox Tables

Outbox pattern คือการสร้าง table ขึ้นมาอาจจะชื่อ outbox table เพื่อทำหน้าที่เป็น temporary storage ของ data changes เมื่อมีการ insert, update หรือ delete จะต้องทำการ insert ข้อมูลที่ outbox table เพื่อเอาไว้เป็น outgoing เมื่อส่งข้อมูลไปยัง event bus สำเร็จ เราจะ update หรือลบข้อมูลใน outbox table แนวคิดนี้ทำให้เรามั่นใจได้ว่าการ data changes ทั้งหมดจะถูกส่งไปยัง event bus

Pros:

• Keeping internal fields: เราสามารถ serialized data ก่อน insert ลง outbox table ได้
• Data consistency and doesn’t lose events: เรามั่นใจได้ว่าหาก event fails ข้อมูลจะเก็บไว้ที่ outbox table

Cons:

• Required application code changes: ต้องแก้ code ในชั้นของ application และเพิ่ม table ใน database
• Performance Impact: มีการ insert ข้อมูลเพิ่มในทุกๆ transactions ที่เกี่ยวกับ data change ที่เราสนใจ

Conclusions

วิธีการเหล่านี้มีความซับซ้อนสูง ยังมีหลากหลายวิธีที่ได้ผลลัพท์คล้ายๆ กัน อยากให้ลอง ttrade-off ข้อดี/ข้อเสีย เรื่องของ effort, maintenance ลองมองจากมุมมองทีม กำลังวัดของเราเอาระบบนี้อยู่ไหม ถ้ามีปัญหาเรามี monitoring หรือ troubleshoot เพื่อแก้ปัญหาได้เร็วแค่ไหนและคำถามสุดท้ายคือ สิ่งที่เรากำลังจะทำตอบ goals ขององค์กรข้อไหน ทั้งจากแว่นตาของ technical และ business

Sample application

The full code for the Change data capture (CDC) can be สนุก on my Github

เผื่อใครสนใจอยากลงเรือ ผมได้ POC: Sample Application โดยใช้ Concept ของ Change data capture (CDC) จำลอง Legacy System ต่อกับ Postgresql และใช้ Debezium เข้าไปอ่าน write-ahead logs เมื่อมี Data Change จะ Publish ข้อมูลไปที่ Kafka และมี Worker คอย Subscribe ทำหน้าที่ยิ่งใหญ่คือการ log ข้อมูลที่ได้ออก console สามารถ pull code แล้วสั่ง docker-compose up -d ได้เลย

Pre-requisites:

• Docker
• Golang
• Nodejs