ในโลกของการพัฒนาระบบที่ซับซ้อน การบันทึกสถานะล่าสุด (Current State) เพียงอย่างเดียวนั้นไม่เพียงพอ นักพัฒนาจึงหันมาให้ความสนใจกับรูปแบบการจัดเก็บข้อมูลที่ทรงพลังอย่าง Event Sourcing (ES) ซึ่งเป็นแนวคิดที่เปลี่ยนจากการบันทึก ‘สถานะ’ ไปเป็นการบันทึก ‘เหตุการณ์’ (Events) ที่เกิดขึ้นทั้งหมดตลอดอายุขัยของเอนทิตี
เมื่อรวมกับความสามารถระดับ Enterprise ของ PostgreSQL ทำให้เราสามารถสร้าง Event Store ที่มีความน่าเชื่อถือสูงและตรวจสอบย้อนหลังได้ (Auditable) บทความนี้จะเจาะลึกวิธีการใช้ PostgreSQL เพื่อ implement Event Sourcing อย่างถูกต้องตามหลักการ
💡 Event Sourcing คืออะไร และทำไมต้องใช้ PostgreSQL?
Event Sourcing คือรูปแบบการจัดเก็บข้อมูลที่แทนที่จะเขียนทับข้อมูลเดิม (Update) เราจะบันทึกเหตุการณ์ที่เกิดขึ้นทั้งหมดในรูปแบบของลำดับ (Sequence) ของ Event ต่างๆ แทน Event แต่ละตัวคือข้อเท็จจริงที่เปลี่ยนแปลงสถานะของระบบ เช่น ‘UserCreated’, ‘OrderPlaced’ หรือ ‘InventoryReduced’
PostgreSQL เหมาะสมอย่างยิ่งสำหรับงานนี้ เพราะมีคุณสมบัติ ACID Compliance ที่ยอดเยี่ยม และรองรับการจัดการข้อมูลเชิงเวลา (Temporal Data) ได้อย่างมีประสิทธิภาพ เราจะใช้ตารางหลักในการเก็บ Event Log และใช้ฟังก์ชันการ Query ที่ซับซ้อนเพื่อ Rehydrate (สร้างสถานะปัจจุบัน) ของเอนทิตี
🛠️ การออกแบบ Event Store ด้วย PostgreSQL
หัวใจของการทำ Event Sourcing คือการมีตารางที่ทำหน้าที่เป็น ‘Event Log’ ซึ่งต้องเก็บข้อมูลสำคัญอย่างน้อย 3 ส่วน: Event ID, Aggregate ID (ID ของเอนทิตีที่เกิดเหตุการณ์), และ Event Payload (รายละเอียดของเหตุการณ์)
เราจะใช้โครงสร้างตารางพื้นฐานดังนี้:
SQL
CREATE TABLE event_store (
event_id UUID PRIMARY KEY,
aggregate_id UUID NOT NULL,
event_type VARCHAR(100) NOT NULL,
event_payload JSONB NOT NULL,
occurred_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP);
การใช้ `JSONB` ใน PostgreSQL ช่วยให้เราสามารถเก็บ Payload ที่มีโครงสร้างหลากหลายได้อย่างยืดหยุ่น ขณะที่ `aggregate_id` ช่วยให้เราสามารถจัดกลุ่มเหตุการณ์ทั้งหมดที่เกี่ยวข้องกับเอนทิตีเดียวได้
🚀 การ Rehydration: การสร้างสถานะปัจจุบัน
การดึงสถานะปัจจุบัน (Current State) ไม่ได้มาจากการ Query ข้อมูลแถวเดียว แต่มาจากการรันคำสั่ง Query ที่เรียงลำดับเหตุการณ์ทั้งหมด (Events) ที่เกิดขึ้นกับ `aggregate_id` นั้นๆ ตั้งแต่ต้นจนถึงล่าสุด
สมมติว่าเราต้องการทราบสถานะของ Order ID: `a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11`:
SQL
SELECT event_type, event_payload FROM event_store
WHERE aggregate_id = 'a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11'
ORDER BY occurred_at ASC;
แอปพลิเคชันจะรับผลลัพธ์นี้เป็นลำดับของเหตุการณ์ แล้วใช้ Business Logic ในการประมวลผลเหตุการณ์เหล่านั้นเพื่อสร้าง Object State ล่าสุดขึ้นมา ซึ่งนี่คือหลักการของ Event Sourcing ที่แท้จริง
✅ ข้อดีในการใช้ Event Sourcing กับ PostgreSQL
1. **Auditability**: ทุกการเปลี่ยนแปลงถูกบันทึกอย่างถาวร ทำให้การตรวจสอบย้อนหลังทำได้สมบูรณ์แบบ
2. **Temporal Querying**: สามารถ Query สถานะของระบบ ณ เวลาใดเวลาหนึ่งในอดีตได้ง่าย (Time Travel)
3. **Decoupling**: ช่วยให้ระบบยืดหยุ่นในการพัฒนา Microservices เพราะแต่ละบริการสามารถ Subscribe (รับฟัง) Event ที่เกิดขึ้นได้โดยตรง
🏁 บทสรุป
Event Sourcing ไม่ใช่แค่เทคนิคการจัดเก็บข้อมูล แต่เป็นแนวคิดในการออกแบบสถาปัตยกรรมระบบที่เน้นความโปร่งใสและความสามารถในการตรวจสอบย้อนหลัง การใช้ PostgreSQL ในการสร้าง Event Store ด้วยการเก็บ Event Log และการใช้ Query เพื่อ Rehydrate สถานะปัจจุบัน ทำให้เราได้ระบบที่มีความน่าเชื่อถือสูง เหมาะสำหรับระบบการเงินหรือระบบที่ต้องการความสมบูรณ์ของข้อมูลในระดับ Enterprise อย่างแท้จริง