Eventual Consistency: เมื่อข้อมูลไม่ตรงกันชั่วคราว เป็นเรื่องปกติของระบบกระจาย
ทำไมยอดไลก์เพิ่งกดถึงยังไม่ขึ้น หรือยอดเงินโอนแล้วยังไม่อัปเดตทันที คำตอบคือ Eventual Consistency การยอมให้ข้อมูลตรงกันในที่สุด แลกกับความเร็วและความพร้อมใช้งานของระบบขนาดใหญ่
ในระบบเล็กที่มีฐานข้อมูลเดียว ข้อมูลตรงกันเสมอทันที แต่เมื่อระบบโตจนต้องกระจายข้อมูลไปหลายเครื่องหลายที่ การให้ทุกที่ตรงกันทุกเสี้ยววินาที กลับทำให้ระบบช้าและเปราะ Eventual Consistency คือการยอมรับว่าข้อมูลอาจไม่ตรงกันชั่วคราว แต่จะตรงกันในที่สุด เพื่อแลกกับความเร็วและความพร้อมใช้งาน
ทำไมต้องยอมแลก
มีหลักการในระบบกระจายที่บอกว่า เมื่อเครือข่ายระหว่างเครื่องมีปัญหา เราต้องเลือกระหว่างความถูกต้องที่ตรงกันทันที กับความพร้อมให้บริการต่อไป ระบบขนาดใหญ่ส่วนมากเลือกให้บริการต่อได้ก่อน แล้วค่อยปรับข้อมูลให้ตรงกันตามมา เพราะการหยุดบริการทั้งระบบเพื่อรอให้ทุกที่ตรงกัน เสียหายกว่าการยอมให้ต่างกันเล็กน้อยชั่วคราว
ออกแบบธุรกิจให้รับความไม่ตรงกันชั่วคราวได้
- แยกว่างานไหนทนความล่าช้าได้ (ยอดไลก์) กับงานที่ต้องตรงทันที (ตัดเงิน)
- สื่อสารกับผู้ใช้ เช่น แสดงสถานะกำลังดำเนินการ แทนที่จะทำเหมือนเสร็จแล้ว
- สำหรับเรื่องเงินและสต็อก ใช้กลไกที่รับประกันความถูกต้องเป็นพิเศษ
การเข้าใจ Eventual Consistency ช่วยให้ผู้บริหารและทีมตั้งความคาดหวังให้ถูก ระบบที่ดีไม่ได้แปลว่าทุกอย่างตรงกันทุกเสี้ยววินาที แต่แปลว่ารู้ว่าตรงไหนต้องตรงทันที และตรงไหนรอได้ การเลือกให้เหมาะกับธุรกิจ คือศิลปะของการออกแบบระบบขนาดใหญ่
บริการที่เกี่ยวข้อง
รับพัฒนาเว็บแอปพลิเคชัน
สร้างเว็บแอปที่รองรับการเติบโตและเชื่อมกับระบบอื่นได้
WhaleScope
ดูโครงสร้างตลาดของทุกหมวดธุรกิจไทย บน WhaleScope
รายชื่อบริษัท ผู้เล่นรายใหญ่ และอัตราคงอยู่ของแต่ละหมวด — จากข้อมูลจดทะเบียน 2 ล้านนิติบุคคล
อ่านต่อ
Saga: จัดการธุรกรรมที่ข้ามหลายระบบ เมื่อ ACID ทำไม่ได้
การจองทริปต้องจองตั๋ว โรงแรม และรถพร้อมกัน แต่ทั้งหมดอยู่คนละระบบ ทำเป็นธุรกรรมเดียวไม่ได้ Saga คือรูปแบบที่ทำทีละขั้น และถ้าขั้นใดล้ม ก็ยกเลิกขั้นก่อนหน้าด้วยการชดเชย
Outbox Pattern: แจ้งข่าวระบบอื่นให้ครบทุกครั้ง ไม่มีหลุดหาย
บันทึกออเดอร์สำเร็จแต่ข้อความแจ้งระบบคลังหายไป สต๊อกก็ไม่ถูกตัด ปัญหาเขียนสองที่พร้อมกันนี้เจอบ่อยกว่าที่คิด Outbox Pattern แก้ด้วยการฝากข้อความไว้ในฐานข้อมูลเดียวกัน แล้วค่อยทยอยส่งให้ถึงแน่นอน
Database Sharding: แบ่งฐานข้อมูลเมื่อใหญ่เกินเครื่องเดียว
เมื่อข้อมูลใหญ่จนเครื่องเดียวรับไม่ไหว การเพิ่มเครื่องให้แรงขึ้นมีเพดาน Sharding คือการแบ่งข้อมูลออกไปหลายเครื่อง ช่วยให้ขยายต่อได้ แต่ก็เพิ่มความซับซ้อนที่ต้องแลก
Serverless: จ่ายตามใช้จริง ไม่ต้องดูแลเซิร์ฟเวอร์
Serverless ให้โค้ดทำงานเมื่อมีคนเรียก แล้วจ่ายตามการใช้จริง โดยไม่ต้องดูแลเซิร์ฟเวอร์ เหมาะกับงานที่โหลดไม่สม่ำเสมอ แต่ก็มีข้อจำกัดที่ต้องเข้าใจก่อนเลือกใช้