CAP Theorem: สามเหลี่ยมพิศวง ที่พระเจ้าบอกว่าคุณเลือกได้แค่ 2 อย่าง!

ลูกค้าถาม: "อยากได้ระบบที่ข้อมูลตรงเป๊ะ 100% ไม่เคยคลาดเคลื่อน และต้องเปิดใช้งานได้ตลอด 24 ชั่วโมงไม่มีวันล่ม แม้สายเคเบิลใต้ทะเลจะขาด!"

โปรแกรมเมอร์ที่ฟังจบได้แต่ยิ้มแห้งๆ ในใจ... ไม่ใช่เพราะเราขี้เกียจ แต่เพราะในโลกคอมพิวเตอร์ มีกฎฟิสิกส์ข้อหนึ่งที่ชื่อว่า CAP Theorem ซึ่งห้ามสิ่งนี้ไว้ตั้งแต่ปี 2000!

📐 สามเหลี่ยมแห่งความจริง: C - A - P

ศาสตราจารย์ Eric Brewer เสนอทฤษฎีว่า ในระบบฐานข้อมูลแบบกระจายศูนย์ (Distributed Database) ที่มีหลายโหนด คุณสามารถเลือกได้ สูงสุดแค่ 2 ใน 3 ข้อนี้เท่านั้น:

• Consistency (ความถูกต้องตรงกัน): ทุกโหนดต้องเห็นข้อมูลเวอร์ชันล่าสุดเหมือนกันเป๊ะ ถามเครื่องไหนก็ได้คำตอบเดียวกันทันที
• Availability (ความพร้อมใช้งาน): ถามอะไรไป ทุกโหนดที่ยังไม่ตายต้องตอบกลับมาเสมอ ห้ามปฏิเสธหรือพ่น Error หน้ามืดใส่ลูกค้า
• Partition Tolerance (ทนทานต่อสายเน็ตขาด): ระบบยังต้องทำงานต่อไปได้ แม้สัญญาณเครือข่ายระหว่าง Server ขาดสะบั้นจนคุยกันไม่รู้เรื่อง

⚡ ความจริงอันโหดร้าย: ข้อ P ห้ามทิ้ง!

ในโลกความเป็นจริง สายเคเบิลขาดได้, สวิตช์เน็ตพังได้, คลาวด์ล่มได้... ดังนั้น Partition Tolerance (P) คือไฟต์บังคับที่คุณต้องเลือกเสมอ

โจทย์จริงจึงเหลือแค่: "ในวันที่สายเน็ตระหว่าง Server กทม. กับ เชียงใหม่ ขาดออกจากกัน คุณจะเลือกอะไรระหว่าง C หรือ A?"

"สมมติลูกค้าโอนเงินเข้าที่เซิร์ฟเวอร์ กทม. แต่ กทม. ส่งสัญญาณไปอัปเดตยอดที่ เชียงใหม่ ไม่ได้เพราะเน็ตขาด... ถ้ามีคนเดินไปกดดูยอดเงินที่ตู้เชียงใหม่ คุณจะสั่งให้ตู้ทำยังไง?"

🥊 2 ฝ่าย 2 อุดมการณ์: CP vs AP

1. ฝ่าย CP (ยอมระบบหยุดดีกว่าตอบข้อมูลมั่ว)

ตู้เชียงใหม่จะขึ้นว่า "ระบบขัดข้องชั่วคราว ไม่สามารถแสดงยอดได้" (ยอมเสีย Availability) เพื่อรักษาความถูกต้องของข้อมูล (Consistency) ไม่ให้แสดงยอดเก่าที่ผิด... เหมาะกับ ระบบบัญชี ธนาคาร และสต็อกสินค้าที่ห้ามขายเกิน

2. ฝ่าย AP (ยอมข้อมูลไม่อัปเดต ดีกว่าหน้าเว็บค้าง)

ตู้เชียงใหม่ยอมโชว์ยอดเงินเก่าไปก่อน (ยอมเสีย Consistency ชั่วคราว) เพื่อให้ลูกค้ายังกดใช้งานต่อได้ (Availability) แล้วค่อยไปแอบ Sync ข้อมูลทีหลังเมื่อเน็ตต่อติด (Eventual Consistency)... เหมาะกับ ยอด Like โพสต์เฟซบุ๊ก หรือฟีดทวิตเตอร์