CAP Theory

CAP dùng để làm gì?

Dùng khi design distributed system

Khi network có vấn đề, hệ thống sẽ hành xử như thế nào?

• Không phải chọn DB
• Là trade-off ở level kiến trúc

3 yếu tố của CAP

C — Consistency - Tính nhất quán

• Tất cả node thấy cùng 1 version data
• Read sau write luôn đúng
• Không trả old/stale data
• Có thể:
• Không liên quan ACID transaction (CAP consistency khác với ACID consistency trong DB.)
• Không đảm bảo latency thấp

A — Availability - Tính sẵn sàng

• Mọi request đều có response (200 / 202)
• Không guarantee data mới nhất
• Hệ thống ưu tiên:
• Response ≠ correct data
• Dù node cao khác có fail hay không, service vẫn trả response (

P — Partition Tolerance - Tính phân tán

• Khi network partition / nodes mất kết nối, hệ thống vẫn hoạt động.
• Message loss / delayed là chuyện bình thường trong distributed system
• Network:
• Distributed system bắt buộc phải chấp nhận P
• Bất kỳ system phân tán nào cũng phải xử lý partition. Chỉ có C và A là trade-off khi P xảy ra

CAP bị hiểu sai như thế nào?

❌ Chọn 2 trong 3

❌ Có hệ thống CA phân tán

❌ AP = dữ liệu sai

✅ Đúng:

• P là bắt buộc
• Khi P xảy ra → chọn C hoặc A
• AP = eventual consistency

Partition xảy ra thì chuyện gì diễn ra?

Khi partition xảy ra → hệ thống phải chọn giữa C hoặc A:

• Nếu ưu tiên Consistency (CP):
• Nếu ưu tiên Availability (AP):

Chỉ khi partition, bạn trade-off C ↔ A.

Giả sử:

• Node A và B mất kết nối

• Node A từ chối request
• Chờ sync với B
• User có thể thấy:

Nếu chọn Availability

• Node A trả data hiện có
• Không chờ B
• User vẫn thao tác bình thường

Các mô hình CAP (thực tế)

CP System

• Strong consistency
• Write thường qua leader
• Failover có thể gây downtime ngắn

Dùng cho: Payment, Booking, Inventory, Authentication

AP System

• Multi-node write
• Conflict resolve sau
• Eventual consistency

Dùng cho: Feed, Notification, Logging, Metrics

CA System

• Chỉ khi:

Eventual Consistency là gì?

• Data không đồng bộ ngay
• Nhưng cuối cùng sẽ đúng
• Có thể xuất hiện:

CAP trong kiến trúc thực tế

Một hệ thống lớn:

• Không có 1 CAP duy nhất
• Mỗi bounded context chọn khác nhau

• Create / Update property → CP
• Price update → CP
• Favorite list → AP
• View count → AP
• Recommendation → AP

CAP và consistency model (nâng cao)

• CAP strong consistency ≠ ACID.
• Có nhiều mức consistency khác:

CAP trong microservices

• Service-to-service call:
• Cần:

• Fail fast
• Reject nếu không chắc chắn

• Accept request
• Process async
• Sync sau

Tự hỏi:

• Feature này sai data được không?
• Sai trong bao lâu?
• User chấp nhận error hay stale data?
• Có cần real-time không?