Kênh support đang yên thì một tin nhắn nhỏ hiện lên: khách vừa đặt hàng, payment đã thành công, nhưng điểm thưởng trên trang profile vẫn là số cũ. Không có gì cháy. Không service nào down. Order là thật, payment là thật, và loyalty update có lẽ đang nằm trong queue rồi. Nhưng từ phía khách hàng, hệ thống vừa tự mâu thuẫn với chính nó.
Đây là phần mà sơ đồ kiến trúc thường che mất khi nói về eventual consistency. Định nghĩa thì đơn giản: các phần khác nhau của hệ thống có thể không đồng ý với nhau trong một khoảng ngắn, nhưng nếu không có thay đổi mới, chúng sẽ dần hội tụ về cùng một sự thật. Trong công việc thật, câu hỏi khó hơn không phải là hệ thống có hội tụ hay không. Câu hỏi là người dùng thấy gì trong lúc nó đang hội tụ, khoảng đó được phép dài bao lâu, và team làm gì khi khoảng đó lặng lẽ dài quá mức.
Strong consistency cho mình một lời hứa dễ chịu. Sau khi write commit, mọi read đều thấy dữ liệu mới. Lời hứa đó rất đáng quý trong một database transaction, và ở vài boundary nó vẫn là lời hứa cần giữ. Nhưng xuyên qua nhiều service, region, cache, search index, analytics pipeline và notification system, đòi hỏi mọi thứ đồng ý ngay lập tức có thể làm product chậm hơn, coupling hơn, và kém available hơn. Eventual consistency thường là trade-off nơi team nói: phần này có thể đúng sau một lát để phần còn lại của hệ thống tiếp tục chạy.
Trade-off đó chỉ ổn khi sự chậm trễ được nói thật. Người dùng thường chấp nhận một search result mất vài giây để thấy document mới tạo. Họ có thể chấp nhận report cập nhật mỗi vài phút. Họ có thể chấp nhận recommendation list đi sau cú click gần nhất. Nhưng họ sẽ khó bình tĩnh nếu bị charge hai lần, mất chỗ đã giữ, hoặc thấy một khoản rút tiền biến mất khỏi số dư ngân hàng. Việc thiết kế quan trọng là tách rõ nơi nào sự thật đến trễ là chấp nhận được, và nơi nào nó sẽ làm mất trust.
Một cách nghĩ hữu ích là consistency budget. Không phải feature nào cũng cần cùng một ngân sách. Trang checkout confirmation có thể cần order record và payment decision được bảo vệ chắc trước khi nói success. Email receipt có thể đến sau. Loyalty points có thể cập nhật sau. Analytics dashboard có thể lag lâu hơn nữa. Khi team không gọi tên những budget này, mọi cuộc nói chuyện trở nên mơ hồ: product nói user bị rối, engineering nói queue vẫn chạy, support nói ticket đang vào, và chưa ai thống nhất độ trễ nào vẫn còn khỏe mạnh.
Product surface phải gánh một phần kiến trúc. Nếu trang profile im lặng trong lúc points đang cập nhật, người dùng sẽ đọc con số cũ như sự thật cuối cùng. Nếu trang nói points are updating, hoặc hiển thị order mới với reward ở trạng thái pending, cùng một độ trễ sẽ bớt giống bug hơn. Đây không chỉ là copy cho đẹp. Đây là UI nói thật về consistency model của hệ thống. Một pending state nhỏ có thể ngăn một support ticket vì nó giải thích khoảng hở trước khi người dùng phải tự đoán.
Hệ thống tốt cũng cố giữ những lời hứa quan trọng nhất cho một người trong một session. Nếu tôi vừa đổi địa chỉ giao hàng, trang tiếp theo tôi nhìn thấy nên phản ánh thay đổi của chính tôi, dù region khác chưa kịp bắt lên. Engineer gọi việc này là read-your-writes. Nếu tôi refresh balance và thấy 120, rồi refresh lần nữa thấy 90 vì trúng replica cũ hơn, hệ thống có thể vẫn eventual consistent, nhưng trải nghiệm sẽ giống hỏng. Monotonic reads, sticky sessions, cache invalidation và routing replica cẩn thận đều là cách làm sự thật đến trễ bớt gây bất ngờ.
Vận hành là nơi eventual consistency trở thành kỷ luật thay vì khẩu hiệu. Team cần biết lag bình thường của từng queue, projection, cache và replica. Team cần alert khi lag vượt budget đã thống nhất, không chỉ khi process crash. Team cần dead-letter queue có người thật sự xem, replay tool có thể rebuild read model an toàn, và reconciliation job so sánh source-of-truth record với các view được dẫn xuất. Nếu không, eventual consistency rất dễ trượt thành accidental inconsistency: dữ liệu đáng lẽ phải bắt kịp, nhưng không bao giờ bắt kịp.
Reconciliation là phần bảo trì lặng lẽ giữ trust đứng vững. Một job chạy ban đêm so sánh paid order với invoice, invoice với email, inventory reservation với stock count, hoặc user action với search index entry. Phần lớn ngày nó không tìm thấy gì đáng kể. Vào ngày nó tìm ra một khoảng lệch, nó cho team một đường sửa rõ ràng trước khi khách hàng trở thành hệ thống monitoring. Eventual consistency dễ sống cùng hơn nhiều khi team có cách quen thuộc để phát hiện và chữa lành sự không đồng ý.
Cũng có một trade-off con người bên trong team. Eventual consistency yêu cầu mọi người ngừng nghĩ theo một đường thẳng duy nhất và bắt đầu nghĩ bằng trạng thái. Thay vì chỉ có success và failed, product có thể cần pending, processing, confirmed, needs review và reconciled. Thay vì giả định một request đã làm xong mọi thứ, support có thể cần biết background step nào đang trễ. Thay vì một dòng log, engineer cần trace, event id, idempotency key và đủ context để lần theo một business action xuyên thời gian.
Sai lầm là trình bày eventual consistency như một điểm yếu hoặc như một huy hiệu kiến trúc cao cấp. Nó không phải cả hai. Nó là một thỏa thuận thực tế về thời gian. Một số sự thật phải được đồng ý ngay. Một số sự thật có thể đi đường vòng. Một số view dẫn xuất có thể được rebuild. Một số độ trễ chỉ chấp nhận được nếu product giải thích nó và operations canh nó. Kiến trúc khỏe khi những thỏa thuận đó đủ rõ để product, engineering, QA, support và operations có thể nói cùng một câu.
Trong đời thật, eventual consistency không phải là thiếu kỷ luật. Nó là kỷ luật được chuyển sang chỗ khác: boundary rõ hơn, product state tốt hơn, lag được đo, retry an toàn, reconciliation, và một cảm nhận chung về lời hứa nào không bao giờ được trễ. Lần tới khi một hệ thống hiển thị giá trị cũ trong vài giây, câu hỏi hữu ích không chỉ là có đang dùng eventual consistency hay không. Câu hỏi là team đã quyết định vài giây đó nghĩa là gì, người dùng nên trải nghiệm nó ra sao, và hệ thống chứng minh thế nào rằng sự thật cuối cùng sẽ tới.