title: "Data Consistency: Hiểu về Eventual Consistency và cách sống chung với nó"
series: "Software Architecture Masterclass"
part: "Phần 3 — Hệ thống Phân tán & Hạ tầng"
order: 22
audience: "Solutions Architect & Technical Lead"
reading_time: "13 phút"
tags: ["data-consistency", "eventual-consistency", "strong-consistency", "read-your-writes", "monotonic-reads", "distributed-systems", "cap-theorem", "replication"]

Data Consistency: Hiểu về Eventual Consistency và cách sống chung với nó

Một khách hàng cập nhật địa chỉ giao hàng, bấm "Lưu", thấy thông báo thành công. Ba giây sau, họ mở lại trang xác nhận đơn hàng — địa chỉ cũ vẫn hiện ra. Họ nghĩ hệ thống lỗi, gọi hotline, agent kiểm tra thấy địa chỉ đã đúng trong DB. Không ai làm gì sai. Request ghi đã đi vào node chính (primary), request đọc sau đó lại rơi vào một replica chưa kịp nhận bản sao mới — một hiện tượng hoàn toàn hợp lệ trong bất kỳ hệ thống nào có replication bất đồng bộ (asynchronous replication).

Đây là lớp bug nguy hiểm nhất trong hệ thống phân tán: không phải vì nó hiếm, mà vì nó không tái hiện được theo yêu cầu. Chạy lại đúng bước đó trên máy dev, mọi thứ đúng ngay — vì latency giữa primary và replica trên localhost gần như bằng 0. Nó chỉ lộ diện khi replica ở khác region, dưới tải cao, hoặc network jitter tăng đột biến. QA không bắt được nó. Test case không cover nó, vì phần lớn kỹ sư viết test với giả định ngầm: "đọc luôn thấy dữ liệu vừa ghi" — tư duy nhất quán mạnh (strong consistency) đóng đinh vào code mà không ai tuyên bố ra miệng.

Vấn đề gốc không nằm ở replica, ở network, hay ở bug cụ thể nào. Nó nằm ở chỗ: hầu hết kỹ sư build ứng dụng phân tán với mental model của một cơ sở dữ liệu đơn instance (single-node), nơi mọi write đều visible với mọi read ngay lập tức theo định nghĩa. Khi hệ thống scale ra nhiều node, nhiều region, nhiều tầng cache — giả định đó âm thầm sai, và không ai cập nhật lại mental model cho kịp.

The Problem

Xét một hệ thống thương mại điện tử điển hình: order được ghi vào MySQL primary, sau đó luồng đọc (cho trang xác nhận, cho dashboard vận hành, cho báo cáo) có thể đi qua bất kỳ đâu trong chuỗi sau — read replica (bản sao chỉ đọc, nhận dữ liệu từ primary qua replication log), Redis cache được invalidate bất đồng bộ, Elasticsearch index được đồng bộ qua CDC (Change Data Capture), hoặc một service khác nhận event OrderCreated qua message broker rồi build read model riêng.

Mỗi tầng trong chuỗi đó đều có một độ trễ giữa "ghi xong ở nguồn" và "đọc thấy ở đích" — có thể vài mili giây, có thể vài giây, có thể lâu hơn nếu có backlog. Kỹ sư viết code cho tầng đọc thường mặc định: gọi API xong, gọi ngay API đọc kế tiếp, kỳ vọng thấy dữ liệu vừa ghi. Giả định này đúng với database single-node truyền thống — sai với gần như mọi kiến trúc phân tán hiện đại có replication, caching, hoặc event sourcing.

Hậu quả cụ thể của giả định sai đó trải khắp codebase:

Race condition trong luồng nghiệp vụ nhiều bước. Service A ghi xong, publish event, Service B nhận event ngay lập tức và query lại chính bảng mà A vừa ghi — nhưng qua một replica chưa kịp đồng bộ. B nhận về dữ liệu cũ, xử lý sai logic, và lỗi này chỉ xảy ra khi replication lag vượt một ngưỡng nhất định.
UI hiển thị dữ liệu "biến mất rồi lại xuất hiện". Người dùng vừa tạo một bản ghi, redirect sang trang danh sách, không thấy bản ghi mới — vì trang danh sách query qua search index đang lag. Refresh vài giây sau lại thấy. Từ góc nhìn người dùng, đây là bug hiển nhiên; từ góc nhìn hệ thống, đây là hành vi đúng thiết kế của một hệ thống eventual consistency không có UX bù đắp.
Test flaky không rõ nguyên nhân. Integration test viết-rồi-đọc-ngay pass 95% số lần chạy, fail ngẫu nhiên 5% còn lại tùy tải hệ thống CI tại thời điểm chạy — vì test giả định nhất quán mạnh trên một hạ tầng chỉ đảm bảo eventual.
Nhất quán bị vi phạm "ngược chiều thời gian". Người dùng đọc dữ liệu mới nhất trong một request, refresh lại, thấy dữ liệu cũ hơn — vì request sau bị load balancer route sang một replica khác, lag nhiều hơn replica trước. Đây là vi phạm monotonic reads (đọc đơn điệu), một đảm bảo mà nhiều đội tưởng "đương nhiên có" nhưng thực ra phải thiết kế mới có.

Gốc rễ của toàn bộ lớp bug này: team không có ngôn ngữ chung để nói về mức độ nhất quán mà từng luồng dữ liệu thực sự cung cấp. Không ai document rõ "endpoint này đảm bảo gì", nên mỗi kỹ sư tự suy diễn theo kinh nghiệm cá nhân — và phần lớn suy diễn sai theo hướng lạc quan hơn thực tế.

The Theory

Nhất quán dữ liệu (data consistency) trong hệ thống phân tân không phải một trạng thái nhị phân "có" hoặc "không" — nó là một phổ (spectrum) các mức đảm bảo, mỗi mức trả giá và mang lại lợi ích khác nhau. Hiểu đúng phổ này là điều kiện tiên quyết để thiết kế đúng, thay vì đoán mò.

Strong consistency (nhất quán mạnh). Mọi read, bất kể đi qua node nào, đều thấy write gần nhất đã được xác nhận (committed). Đây là mô hình mà database single-node cung cấp miễn phí, và là mô hình mà hầu hết kỹ sư mang theo làm mặc định tinh thần khi bước vào thế giới phân tán. Để đạt được nó trong hệ phân tán, hệ thống phải trả giá bằng một hình thức đồng thuận (consensus) hoặc route mọi read/write qua cùng một node có thẩm quyền (authoritative) — cả hai đều đội thêm latency và giảm khả năng chịu lỗi.

Bounded staleness (độ trễ có giới hạn). Hệ thống cam kết read không bao giờ trễ hơn dữ liệu ghi quá một ngưỡng xác định — ví dụ tối đa 5 giây hoặc tối đa N phiên bản (version) so với write mới nhất. Đây là một thỏa hiệp có chủ đích: không nhất quán tức thời, nhưng có một cận trên rõ ràng mà nghiệp vụ có thể lập kế hoạch xung quanh (ví dụ: dashboard báo cáo "dữ liệu cập nhật tới X phút trước").

Read-your-writes (đọc thấy chính write của mình). Đảm bảo yếu hơn strong consistency toàn cục, nhưng đủ mạnh cho phần lớn trải nghiệm người dùng: một user, sau khi tự mình ghi dữ liệu, sẽ luôn đọc thấy chính write đó trong các lần đọc tiếp theo của họ — dù người dùng khác có thể chưa thấy ngay. Đây thường là mức tối thiểu cần cho UX "lưu xong, thấy ngay kết quả" mà không cần trả giá của strong consistency toàn hệ thống.

Monotonic reads (đọc đơn điệu). Đảm bảo một khi user đã đọc thấy một phiên bản dữ liệu nào đó, các lần đọc sau sẽ không bao giờ thấy phiên bản cũ hơn — dù dữ liệu ở các node khác nhau có lag khác nhau. Không có đảm bảo này, người dùng có thể trải nghiệm dữ liệu "đi lùi theo thời gian" giữa các lần load trang, một trong những trải nghiệm gây mất niềm tin nhiều nhất dù bản thân dữ liệu không sai.

Eventual consistency (nhất quán rốt cuộc). Đảm bảo yếu nhất còn có ý nghĩa: nếu không còn write mới nào xảy ra, tất cả các bản sao rốt cuộc sẽ hội tụ về cùng một giá trị — nhưng không cam kết gì về việc bao lâu, và không cam kết gì về trạng thái trung gian trong lúc chờ hội tụ. Đây là mức đảm bảo rẻ nhất về chi phí latency/availability, và cũng là mức mặc định của phần lớn hạ tầng caching, search index, và read model bất đồng bộ hiện đại — dù ít khi được gọi đích danh trong thiết kế.

Điểm mấu chốt về mặt lý thuyết: các mức này không xếp theo thứ tự "tốt hơn — tệ hơn" tuyệt đối. Chúng xếp theo thứ tự chi phí vận hành đổi lấy đảm bảo dữ liệu, và lựa chọn đúng phụ thuộc hoàn toàn vào việc nghiệp vụ cụ thể chịu được độ trễ dữ liệu nào — không có câu trả lời chung cho mọi hệ thống, chỉ có câu trả lời đúng cho từng luồng nghiệp vụ cụ thể.

The Trade-off

Đây là phần không được phép mơ hồ: mỗi mức nhất quán mua một thứ và bán một thứ, cụ thể như sau.

Chọn strong consistency — được gì, mất gì:

Được: lập trình đơn giản hơn hẳn — kỹ sư không phải nghĩ về staleness, code viết-rồi-đọc-ngay luôn đúng, không có lớp bug "race condition do lag" phải săn lùng.
Mất: mọi write (và thường cả read, tùy mô hình) phải đi qua một điểm đồng thuận hoặc một node thẩm quyền duy nhất, kéo theo latency tăng (đặc biệt nếu node đó ở xa về địa lý) và giảm khả năng chịu lỗi — nếu node/quorum đó không khả dụng, toàn bộ ghi (và có thể cả đọc) phải dừng lại thay vì phục vụ dữ liệu cũ. Đây chính là mặt "C thắng A" của CAP Theorem khi mạng phân vùng.

Chọn read-your-writes / monotonic reads — được gì, mất gì:

Được: UX người dùng cá nhân mượt mà gần như nhất quán mạnh (họ luôn thấy write của chính mình, không bao giờ thấy dữ liệu "đi lùi"), trong khi hệ thống vẫn giữ được phần lớn lợi ích về khả năng mở rộng và chịu lỗi của kiến trúc phân tán.
Mất: phải trả chi phí kỹ thuật để cài đặt các đảm bảo này — thường là session affinity (ghim một user vào cùng một node/replica trong phiên làm việc), hoặc theo dõi version/timestamp của write gần nhất để route read đúng chỗ. Đây không phải "miễn phí đi kèm broker/cache" — phải chủ động thiết kế.
Vẫn còn giới hạn: user khác (không phải người vừa ghi) vẫn có thể thấy dữ liệu cũ trong một cửa sổ thời gian nhất định — nếu nghiệp vụ cần "mọi người thấy đồng thời", mức này chưa đủ.

Chọn eventual consistency thuần túy — được gì, mất gì:

Được: latency thấp nhất, khả năng chịu lỗi cao nhất, khả năng mở rộng theo chiều ngang gần như không giới hạn — mỗi node/replica có thể phục vụ read độc lập, không cần chờ đồng thuận, không cần route qua một điểm trung tâm.
Mất: nghiệp vụ và UX phải chủ động chấp nhận và xử lý độ trễ dữ liệu. Nếu không thiết kế bù đắp (ví dụ: optimistic UI cập nhật ngay phía client trước khi server xác nhận, banner "dữ liệu có thể trễ vài giây", hoặc idempotency để chịu được việc đọc phải dữ liệu tạm thời mâu thuẫn), người dùng sẽ trải nghiệm hệ thống như "lỗi vặt" liên tục dù về mặt kỹ thuật không có gì sai.
Rủi ro ẩn: các luồng nghiệp vụ nhiều bước (A ghi, B đọc ngay để quyết định hành động) có thể ra quyết định sai dựa trên dữ liệu chưa hội tụ, và lỗi này không lộ diện trong test bình thường — nó là loại bug chỉ xuất hiện dưới tải thật, khó tái hiện, khó debug nhất trong toàn bộ hệ thống.

Nói ngắn gọn: nhất quán mạnh hơn luôn đi kèm latency cao hơn và/hoặc availability thấp hơn — không có ngoại lệ, đây là hệ quả trực tiếp của việc phối hợp trạng thái giữa nhiều node qua một mạng không đáng tin cậy tuyệt đối. Nhất quán yếu hơn luôn đòi hỏi nghiệp vụ và UX phải "biết và chấp nhận" độ trễ đó một cách tường minh — nếu không tường minh, nó biến thành bug, không phải trade-off có chủ đích.

The Architecture Diagram

Sơ đồ dưới thể hiện phổ tuyến tính các mô hình nhất quán, sắp theo trục "chi phí latency/availability" (trái = tốn nhiều nhất) và "độ trễ dữ liệu mà nghiệp vụ phải chấp nhận" (phải = chấp nhận nhiều nhất).

flowchart LR
    subgraph SPECTRUM["Phổ các mô hình Data Consistency"]
        direction LR
        A["Strong Consistency<br/>━━━━━━━━━<br/>Mọi read thấy write<br/>gần nhất, mọi lúc<br/><br/>Chi phí: latency cao,<br/>availability thấp khi<br/>partition"]
        B["Bounded Staleness<br/>━━━━━━━━━<br/>Read trễ tối đa<br/>N giây / N version<br/><br/>Chi phí: vừa phải,<br/>có cận trên rõ ràng"]
        C["Read-Your-Writes<br/>━━━━━━━━━<br/>User luôn thấy<br/>write của chính mình<br/><br/>Chi phí: cần session<br/>affinity / version tracking"]
        D["Monotonic Reads<br/>━━━━━━━━━<br/>Không bao giờ thấy<br/>dữ liệu 'đi lùi'<br/><br/>Chi phí: route read<br/>theo phiên nhất quán"]
        E["Eventual Consistency<br/>━━━━━━━━━<br/>Rốt cuộc sẽ hội tụ,<br/>không cam kết bao lâu<br/><br/>Chi phí: gần như 0,<br/>availability cao nhất"]
    end

    A -->|"nới lỏng đảm bảo"| B --> C --> D --> E

    style A fill:#ffebeb,stroke:#c0392b
    style B fill:#fff3e0,stroke:#e67e22
    style C fill:#fffde7,stroke:#f1c40f
    style D fill:#e8f5e9,stroke:#27ae60
    style E fill:#e3f2fd,stroke:#2980b9

Đọc sơ đồ theo hai chiều: đi từ trái sang phải, mỗi bước nới lỏng đảm bảo đổi lấy latency thấp hơn và availability cao hơn. Đi từ phải sang trái, mỗi bước siết chặt đảm bảo đổi lấy sự đơn giản trong tư duy lập trình — nhưng luôn phải trả bằng chi phí hạ tầng và hiệu năng. Không có điểm nào trên phổ này là "mặc định đúng" — điểm đúng là điểm khớp với yêu cầu thực tế của từng luồng nghiệp vụ cụ thể, và các luồng khác nhau trong CÙNG một hệ thống hoàn toàn có thể nằm ở các điểm khác nhau trên phổ này.

Implementation Guardrails

Ghi lại rõ ràng, bằng văn bản, mức đảm bảo nhất quán của từng endpoint/luồng đọc — không được để ngầm định. Mỗi API đọc dữ liệu (đặc biệt là đọc qua cache, search index, read replica, hay read model dựng từ event) phải có một dòng ghi chú tường minh: "endpoint này đảm bảo read-your-writes" hoặc "endpoint này eventual, độ trễ thường dưới X giây". Đây không phải chi tiết vặt — nó là hợp đồng giữa backend và mọi consumer (frontend, service khác, đội vận hành) về việc dữ liệu trả về có thể trễ đến đâu.
Không bao giờ ngầm giả định nhất quán mạnh trong lời gọi phân tán, kể cả khi hai service tưởng như "cùng một transaction logic". Bất kỳ đoạn code nào có dạng "ghi ở A, đọc ngay ở B để quyết định hành động tiếp theo" phải được review với câu hỏi tường minh: nếu B đọc phải dữ liệu cũ 500ms, hệ thống có ra quyết định sai không? Nếu có, hoặc phải đổi sang đọc trực tiếp từ nguồn ghi (route về primary), hoặc phải thiết kế lại luồng để không phụ thuộc vào tính tức thời đó (ví dụ: truyền thẳng dữ liệu qua event payload thay vì bắt B tự query lại).
Với luồng cần read-your-writes, cài đặt cơ chế cụ thể — đừng hy vọng nó "tự nhiên đúng". Hai cách phổ biến: (a) route mọi read của một session về cùng node/replica đã nhận write gần nhất (session affinity, thường qua sticky routing hoặc version token truyền kèm request); (b) client tự giữ optimistic state sau khi ghi thành công, không phụ thuộc vào việc gọi lại API đọc ngay lập tức. Chọn cách nào tùy vào kiến trúc, nhưng phải chọn chủ động — không được để mặc định "may thì đọc lại đúng, rủi thì thôi".
Với mọi hệ thống dùng eventual consistency, thiết kế UX/nghiệp vụ phải phản ánh đúng thực tế đó, không giả vờ nó là tức thời. Hiển thị trạng thái trung gian rõ ràng (ví dụ "đang xử lý", "đang đồng bộ") thay vì để UI trông như đã hoàn tất trong khi dữ liệu backend chưa hội tụ; với luồng nghiệp vụ tài chính hoặc có tính pháp lý, đánh giá kỹ xem eventual consistency có thực sự chấp nhận được hay bắt buộc phải trả giá cho strong consistency ở đúng điểm quyết định đó (không nhất thiết toàn hệ thống).

Architect's Verdict

Nhất quán mạnh không phải "mặc định an toàn" miễn phí — nó là một lựa chọn kiến trúc có giá, và cái giá đó (latency, availability) bị trả bởi toàn bộ hệ thống, mọi lúc, kể cả 99% thời gian khi chẳng ai cần đến sự đảm bảo tức thời đó. Nguyên tắc thực chiến: chọn mức đảm bảo nhất quán yếu nhất mà logic nghiệp vụ ở đúng luồng đó có thể chịu được — không phải yếu nhất mà hệ thống có thể chạy được, và không phải mạnh nhất cho "chắc ăn". Phần lớn luồng đọc (dashboard, danh sách, báo cáo, feed) chịu được eventual hoặc bounded staleness hoàn toàn thoải mái; chỉ một số ít luồng thực sự cần strong consistency (số dư tài khoản trước khi trừ tiền, kiểm tra tồn kho trước khi xác nhận đơn) — và ngay cả ở đó, hãy giới hạn phạm vi strong consistency chỉ vào đúng bước quyết định, đừng lan nó ra toàn hệ thống vì tâm lý "cho chắc".

🔗 Bài viết liên quan: CAP Theorem · SAGA Pattern — Giao dịch phân tán

Bài trước: CAP Theorem · Bài tiếp theo: Distributed Caching