โดย Denis Koessler Gosnell, PhD
ถ้าเราออกแบบระบบแบบมี one master register แล้วให้ bookstore ที่ต่าง ๆ มาเชื่อมต่อกับ master เราก็สามารถมี strong consistency แต่ถ้าเมื่อไหร่ก็ตามที่ master ล่มแล้ว จะทำให้ทุก ๆ bookstore ไม่สามารถซื้อขายได้ทันที
ซึ่งแทนที่เราจะปล่อยให้ลูกค้าหัวเสียไป เราสามารถที่จะแก้ปัญหานี้ได้ในหลาย ๆ วิธี
เราอาจจะอัพเดทข้อมูลแต่ละ store เป็นรายวันตอนปิดร้าน ซึ่งแบบนี้เราเรียกว่า eventual consistency คือท้ายที่สุดแล้ว ทุก ๆ bookstore ก็จะมีข้อมูลที่อัพเดทเท่ากันหมด
เราสามารถจัดการกับ inconsistencies ได้ โดยใช้วิธี “read repair” คือเมื่อเราเจอ inconsistency เมื่อไหร่ เราก็รัน process เพื่ออัพเดทค่าต่าง ๆ ให้ล่าสุด
การทำ eventual consistency นั้นทำให้ architect ของระบบเราไม่เข้มงวดมากในเรื่องการป้องกันไม่ให้ master ล่ม
สุดท้ายแล้ว ทั้ง strong consistency กับ eventual consistency ก็มีข้อดีข้อเสียแตกต่างกันไป เราต้องเลือกใช้ให้เหมาะกับสถานการณ์ เช่น ถ้าต้องการ scale แบบ client/server เราก็อาจจะเลือกออกแบบเป็นแบบ strong consistency แต่ถ้าอยากจะรับโหลดเยอะ ๆ แล้วก็แก้เรื่อง inconsistencies ตอนที่เจอ เราก็อาจจะเลือกออกแบบให้เป็นแบบ eventual consistency