[Design System] CAP Theorem & Consistency Patterns

[DS]CAP-ConsistencyPatterns.md

CAP Theorem & Consistency Patterns: From Theory to Practice

Hiểu về CAP Theorem không chỉ dừng ở lý thuyết suông; đây là vũ khí để bạn đưa ra các quyết định kiến trúc (Architecture Decision Records - ADRs) sắn bén. Trong thế giới phân tán (Distributed Systems), mạng không bao giờ tin cậy được (Partition Tolerance là hiển nhiên). Vì vậy, cuộc chơi thực sự nằm ở việc bạn chấp nhận hy sinh Consistency (C) hay Availability (A) khi sự cố xảy ra.

Dưới đây không phải là bài giảng hàn lâm, mà là playbook đúc kết các trade-off thực tế để bạn áp dụng ngay vào bản thiết kế của mình.

1. Top 10 Chiến thuật đánh đổi (The Trade-off Playbook)

#	Chiến thuật (Gain/Pain)	Bản chất kỹ thuật (Deep Dive)
1	Chọn CP (Consistency over Availability) Được: Dữ liệu luôn đúng và mới nhất (Atomic). Mất: Sẵn sàng hy sinh trải nghiệm người dùng: request sẽ bị lỗi hoặc treo (timeout) nếu có sự cố mạng.	Hệ thống thà "chết" (unavailable) còn hơn trả về dữ liệu sai. Nó phải chờ node bị phân tách phản hồi thì mới dám confirm.
2	Chọn AP (Availability over Consistency) Được: Hệ thống "bất tử", luôn trả lời request cực nhanh. Mất: Dữ liệu có thể là đồ cũ (stale). Nhất quán chỉ là chuyện "sớm muộn" (eventual). ⚠️ Sau khi P được kết nối lại: • Dữ liệu cũ (write trong lúc partition) KHÔNG tự động đồng bộ - cần cơ chế recovery. • Write mới sẽ được đồng bộ bình thường - nhưng data loss từ partition window là vĩnh viễn nếu không có recovery mechanism. 🔧 Các cơ chế Recovery trong Production: • Anti-entropy repair (Cassandra): Background process chạy định kỳ so sánh dữ liệu giữa các nodes và tự động sync phần khác biệt. Giống như "đối soát sổ sách" tự động. • Hinted handoff (DynamoDB): Node còn sống lưu "ghi chú" về writes cần gửi cho node đang offline. Khi node online lại, ghi chú được replay để bù dữ liệu thiếu. • Read repair: Khi client đọc dữ liệu, hệ thống phát hiện inconsistency giữa các replicas và trigger sync ngay lập tức. "Vá lỗ hổng" theo kiểu lazy. • Merkle trees (Cassandra/DynamoDB): So sánh hash tree của toàn bộ dataset để nhanh chóng tìm ra phần dữ liệu nào khác biệt, tránh phải so sánh từng record. • Gossip protocol (Cassandra): Các nodes "tán gẫu" với nhau về metadata và phát hiện ai đang có dữ liệu cũ, sau đó tự động đồng bộ. • Manual reconciliation: Script đối soát chạy batch job để fix data inconsistency - phương án cuối cùng khi các cơ chế tự động thất bại.	Thích hợp cho các feature "nhìn thấy là được", không cần chính xác tuyệt đối từng mili-giây (ví dụ: like count, news feed).
3	Strong Consistency (2PC/Paxos) Được: Chắc chắn như "bàn thạch". Tiền đã trừ là trừ, không có chuyện trừ xong rollback ngầm. Mất: Chậm. Rất chậm. Latency tăng vọt và Throughput giảm thê thảm.	Sync replication buộc hệ thống phải chờ đa số (majority) gật đầu. Chỉ dùng cho những logic "sống còn" (tiền nong, inventory).
4	Eventual Consistency Được: Tốc độ bàn thờ. Scale dễ dàng. Mất: Có những khoảnh khắc người dùng thấy dữ liệu "ma" (vừa xóa xong F5 vẫn thấy).	Writes thành công ngay lập tức ở local, sau đó mới âm thầm đồng bộ sang chỗ khác.
5	Master-Slave Replication (Async) Được: Ghi nhanh như gió (vì ghi local master). Vẫn an toàn hơn Single DC. Mất: Nếu Master chết bất đắc kỳ tử trước khi kịp sync sang Slave --> Mất dữ liệu vĩnh viễn (Data Loss Window).	Trade-off kinh điển: Hy sinh một chút rủi ro mất data để đổi lấy Performance ngon nghẻ.
6	Paxos/Raft (Distributed Consensus) Được: "Chuẩn không cần chỉnh" (Strong Consistency) mà vẫn chịu lỗi tốt (không cần 100% node sống). Mất: Chi phí vận hành cực cao. Cực khó debug. Latency cũng không hề dễ chịu.	Chỉ dành cho các hệ thống nền tảng (Core Infrastructure) như ZooKeeper, Etcd, Consuls. Đừng dùng lung tung cho App Logic.
7	Weak Consistency (Caching/VoIP) Được: Real-time, siêu nhanh. Mất: Rớt gói tin? Kệ nó. Dữ liệu cũ? Chấp nhận luôn.	Dùng cho Video Streaming, VoIP, Game realtime hoặc Cache layer.
8	Geo-locality (Đa vùng) Được: Người dùng ở đâu phục vụ ở đó (Low Read Latency). Mất: Tiền server và băng thông (Backbone cost) sẽ làm bạn "đau ví". Đồng bộ dữ liệu xuyên lục địa là ác mộng về độ trễ.	Cân nhắc kỹ: Chỉ nên edge caching hay cần full replication?
9	Single Data Center (Đơn giản là nhất) Được: Mọi thứ đều nhanh (Local LAN), rẻ và dễ quản lý. Mất: "Bỏ hết trứng vào một giỏ". Sập DC là sập tiệm (Catastrophic Failure).	Phù hợp giai đoạn đầu (Startups) hoặc các hệ thống internal không quá critical.
10	Cross-DC Transactions (2PC) Được: An toàn tuyệt đối bất chấp địa lý. Mất: Hiệu năng thảm hại. Một node mạng chập chờn ở Mỹ có thể kéo sập cả giao dịch ở Việt Nam.	"Dao mổ trâu": Chỉ dùng khi pháp lý hoặc business bắt buộc phải vậy.

2. Bảng quyết định kiến trúc (ADR Cheat Sheet)

Dưới đây là bảng "phao" để bạn chọn vũ khí phù hợp, tránh việc dùng dao mổ trâu giết gà:

Option	Điểm mạnh (Pros)	Điểm yếu (Cons)	Khi nào dùng?	Né ngay khi...	Cái giá ngầm (Hidden Costs)
CP	Chắc chắn đúng (Strong Consistency). Lý tưởng cho Core Banking, Payment.	Giảm Uptime. User sẽ thấy lỗi khi mạng có vấn đề.	Cần đúng tuyệt đối, sai 1 li đi 1 dặm.	Cần High Availability, quy mô user toàn cầu.	Client phải code xử lý lỗi/retry cực khéo, nếu không sẽ tự DDOS chính mình.
AP	Luôn available. Trải nghiệm mượt mà.	Dữ liệu có thể sai lệch tạm thời (Stale).	E-commerce (giỏ hàng), Social, DNS.	Quản lý kho, Số dư tài khoản.	Code xử lý conflict (merge data) ở tầng App chua hơn bạn tưởng.
Master-Slave (Async)	Write nhanh. DR (Disaster Recovery) tốt.	Slave đọc có thể thấy data cũ. Rủi ro mất data khi Master chết.	Read-heavy apps. Cần cân bằng giữa Speed và Safety.	Yêu cầu user A vừa ghi xong user B bên kia địa cầu phải thấy ngay.	Xây dựng quy trình Promote Slave lên Master không downtime là cả một nghệ thuật.
2PC (Two-Phase Commit)	Nhất quán tuyệt đối xuyên server/DC.	Chậm, dễ bị blocking/deadlock. Cổ chai hiệu năng.	Giao dịch tài chính giá trị cao, ít DC.	Cần High Throughput, Web Scale.	Coordinator trở thành điểm nghẽn (Single point of failure/bottleneck).
Paxos/Raft	Mạnh mẽ, tự động bầu chọn Master mới, không cần can thiệp thủ công.	Khó hiểu, khó cài đặt, latency cao cho thao tác ghi.	Hệ thống điều phối (Coordination services), metadata store.	Cần low-latency cho user facing request.	Đòi hỏi team vận hành (SRE) trình độ cao mới handle nổi khi có sự cố.

3. Nhật ký chiến trường: 8 Kịch bản lỗi (Incident Response)

Thực tế production khắc nghiệt hơn lý thuyết. Đây là những gì sẽ xảy ra và cách bạn đối mặt:

#	Triệu chứng (Symptom)	Nguyên nhân gốc rễ (Root Cause)	Cách đỡ đòn (Mitigation)	Hồi sức (Recovery)
1	Write Timeout tăng vọt (Tỉ lệ lỗi cao bất thường)	Network Partition: Các DC bị cắt liên lạc. "Não" bị chia cắt.	Hệ thống CP: Fail fast (trả lỗi ngay cho user). Hệ thống AP: Ghi tạm vào local (chấp nhận rủi ro).	Chờ mạng thông, chạy cơ chế Sync (Gossip/Anti-entropy) để vá dữ liệu.
2	User than phiền thấy dữ liệu cũ (Vừa update xong F5 vẫn như cũ)	Replication Lag: Master chưa kịp đẩy data sang Slave chỗ user đọc.	Thiết kế UI lừa tình (Optimistic UI). Hoặc dùng Sticky Session (đọc ngay tại nơi vừa ghi).	Không cần làm gì cả, AP nó thế. Giải thích cho PM hiểu.
3	App treo cứng, xoay vòng vòng	Không set Timeout: App ngây thơ chờ đợi một response không bao giờ đến.	Luôn set Timeout và dùng Circuit Breaker cho mọi network call.	Restart service. Điều tra xem bottleneck ở đâu.
4	Sập toàn tập (DC Outage) (Mất điện, cá mập cắn cáp)	Single Point of Failure: Chỉ chạy ở 1 DC hoặc config sai High Availability.	Phải thiết kế Multi-DC redundancy từ đầu. Test DR định kỳ.	Kích hoạt quy trình Failover (chuyển traffic sang DC dự phòng). Chấp nhận mất ít data nếu dùng Async replication.
5	Hệ thống chậm dần đều	Tắc đường (Bottleneck): Traffic tăng nhưng architecture không scale được.	Sharding (chia nhỏ database). Thêm Cache. Rate limit bớt request rác.	Scale out server (thêm máy). Tắt bớt tính năng phụ (Degradation).
6	Tiền mất tật mang (Inconsistent Data)	Lỗi Transaction: Commit một nửa (Partial commit) do lỗi mạng giữa chừng.	Đã đụng đến tiền là phải dùng Strong Consistency (2PC) hoặc Saga Pattern cẩn thận.	Chạy script đối soát (Reconciliation) để sửa data bằng tay hoặc bù trừ (Compensating transactions).
7	Một con sâu làm rầu nồi canh (Slow Node)	Straggler: Một node bị đơ (do GC, ổ cứng hỏng) làm chậm cả hệ thống.	Monitoring P99 Latency. Dùng Load Balancer thông minh để né node chậm.	Cách ly (Quarantine) node đó ra khỏi pool, chờ sửa xong cho vào lại.
8	Hóa đơn Cloud tăng chóng mặt	Cross-AZ/Region Traffic: Copy data qua lại giữa các vùng quá nhiều thừa thãi.	Tối ưu luồng dữ liệu. Chỉ replicate cái gì thực sự cần (Need-to-know basis).	Review lại architecture xem có đang "dùng dao mổ trâu" cho data rác không.

Chúng ta cần chuyển tư duy từ việc "chọn C hay A" sang "quản lý trade-off C-A trong các kịch bản lỗi (P)". Hệ thống phân tán, đặc biệt là các ứng dụng web quy mô lớn như Coffee App, luôn bị chi phối bởi các giới hạn về độ trễ (latency), băng thông (bandwidth) và tính nhất quán (consistency).

4. Giải mã điểm nghẽn & Chiến lược Scaling (Bottlenecks & Scaling)

Trong thực tế, các điểm tắc nghẽn thường xuất phát từ việc chúng ta ảo tưởng về mạng lưới (Fallacies of Distributed Computing). Dưới đây là cách bắt mạch và kê đơn:

Bottleneck (Điểm tắc)	Nguyên nhân sâu xa (Root Cause)	Tác động (Impact)	Chiến lược Scale (Action Plan)
Serialization Point	Các giao thức Strong Consistency (2PC, Paxos) buộc phải xếp hàng (serialize) transaction qua một Coordinator/Leader.	Low Throughput & High Latency. Đặc biệt nghiêm trọng khi các DC nằm xa nhau (độ trễ round-trip cao).	Sharding: Chia nhỏ phạm vi transaction (Entity Group Sharding). Đừng cố lock cả thế giới, chỉ lock những gì cần thiết.
Partition-induced Stall	Cố chấp chọn CP khi mạng bị chia cắt. Hệ thống chờ node bị mất tích trả lời.	Availability giảm thê thảm. User gặp timeout hoặc chờ vô vọng.	Circuit Breakers & Timeouts: Fail fast là thượng sách. Khi thấy độ trễ tăng vọt, chuyển ngay sang chế độ AP hoặc trả lỗi ngay lập tức để giải phóng tài nguyên.
Hot Key / Hot Shard	Phân bố dữ liệu không đều (Skewed workload). Một vài key nhận traffic gấp 100 lần key khác.	Nghẽn cổ chai cục bộ. Một shard quá tải sẽ kéo lùi hiệu năng cả hệ thống.	Re-sharding tự động: Sử dụng DB có khả năng tự cân bằng tải. Nếu không, phải dùng Write Throttling hoặc Load Shedding cho các Hot Key đó.
Replication Lag & Network Cost	Sync data giữa các DC một cách ngây thơ (copy toàn bộ).	Stale Reads & Hóa đơn mạng khổng lồ.	Tối ưu Replication: Chỉ gửi Log diff thay vì Snapshot. Tận dụng Geo-locality để Slave gần user nhất phục vụ Read.

5. Bộ công cụ giám sát (Observability Pack)

Không đo lường thì không cải thiện được. Đây là những chỉ số "mạch máu" mà SRE cần watch 24/7:

Tín hiệu (Metrics)	Tại sao quan trọng?	Ngưỡng báo động (Threshold)	Hành động của Operator (Runbook)
Request Latency (P99)	Chỉ số tiên quyết của User Experience. Cao bất thường = Tắc nghẽn hoặc Node chậm.	P99 > 100ms (Writes Multi-DC) hoặc > 30ms (Writes Local).	Critical (PagerDuty): Kiểm tra Circuit Breakers. Tìm node "con sâu làm rầu nồi canh" để cách ly ngay.
Error Rate (5xx)	Đo lường mức độ "chết" của hệ thống. Dấu hiệu của CP mode đang reject request.	> 0.1% tổng traffic.	Critical: Kích hoạt Failover hoặc Scale Out. Check logs xem có phải lỗi mạng liên DC không.
Replication Lag	Đo lường "độ cũ" của dữ liệu. Quyết định trải nghiệm Eventual Consistency.	> 5s (hoặc tuỳ business SLA).	Warning: Kiểm tra băng thông backbone. Replica có đang bị quá tải CPU không xử lý kịp log không?
Cross-DC Drop Rate	Dấu hiệu sớm của Partition. Mạng trục trặc là khởi đầu của mọi rắc rối.	Packet loss > 1%	Critical: Xác nhận sự cố mạng. Hệ thống phải chuyển sang mode phòng thủ (CP hoặc AP) theo kịch bản đã định.

6. Sizing Nhanh: Bài toán Coffee App 10k RPS

Dưới đây là bài toán ước lượng tài nguyên (Back-of-the-envelope estimation) để bạn có cái nhìn định lượng cho hệ thống quy mô vừa (Coffee App).

Giả định:

1. Traffic: 10,000 RPS (Requests Per Second) lúc cao điểm.
2. Payload: Trung bình 5KB/Request.
3. Architecture: 3 Data Centers (Multihoming) để đảm bảo HA/DR.

A. Throughput & Volume

• QPS đỉnh: 10,000 req/s.
• Tổng requests/ngày: ~172.8 triệu requests (Giả sử traffic trung bình bằng 20% traffic đỉnh trong 24h).

B. Băng thông (Bandwidth Planning)

Cần phân biệt rõ băng thông phục vụ User (External) và băng thông đồng bộ nội bộ (Internal Replication).

Metric	Cách tính	Kết quả	Ghi chú (Hidden Cost)
External Bandwidth (Client I/O)	10k RPS * 5KB * 2 (In/Out)	~800 Mbps	Đây là traffic Internet (CDN/LB). Chia đều cho 3 DC thì mỗi DC chịu tải nhẹ nhàng.
Internal Backbone (Replication)	100 MB/s Write * 2 Replicas	~1.6 Gbps	CHI PHÍ ẨN LỚN: Traffic này chạy trên đường truyền riêng (Backbone) giữa các DC, đắt đỏ hơn Internet thường. Cần tối ưu protocol.

C. Lưu trữ (Capacity Planning)

Giả sử tỉ lệ Write là 20% (2,000 RPS). Lưu trữ trong 1 năm.

• Write Volume: ~173 triệu records mới mỗi ngày.
• Raw Data/Năm: 173M * 365 * 5KB ≈ 315 TB.
• Tổng lưu trữ (3 Replicas): 315 TB * 3 ≈ ~1 PB (Petabyte).

  Lưu ý: Thực tế cần cộng thêm 30-50% cho Index, Metadata và Snapshot backup.

D. Bộ nhớ Cache (Redis/Memcached)

Cache là lớp phòng thủ đầu tiên. Chúng ta cần cache "Working Set" (dữ liệu nóng).

• Working Set (1 giờ cao điểm): 10k RPS * 3600s * 5KB ≈ 180 GB.
• Chiến lược: Cần cluster Redis với RAM tối thiểu 200GB - 256GB để đảm bảo hit-rate cao.

---

Lời kết: Với quy mô 10k RPS, "chìa khóa" không phải là máy mạnh (Vertical Scaling) mà là kiến trúc Sharding & Async Replication. Hãy dùng Master-Slave Async để đảm bảo Performance cho 99% tác vụ, và chỉ dùng Strong Consistency (Paxos) cho 1% tác vụ nhạy cảm liên quan đến túi tiền của khách hàng.

7. Tổng kết: CAP & Consistency Patterns (Senior Architect Note)

Làm kiến trúc không phải là học thuộc lòng định lý, mà là hiểu sâu sắc những điểm neo chốt (anchors) để ra quyết định. Dưới đây là 5 "nguyên tắc vàng" và bảng ma trận quyết định giúp bạn định hướng nhanh trong mọi cuộc tranh luận kỹ thuật.

5 Điểm Cốt Lõi (Core Strategic Insights)

1. Partition Tolerance (P) là Mệnh Lệnh:

   • Mạng không bao giờ đáng tin cậy (Fallacy of Distributed Computing).
   • Do đó, P là bất biến. Quyết định của bạn chỉ còn là hy sinh C hay A khi Partition xảy ra.

2. Consistency là Định nghĩa "Mạnh":

   • Trong CAP, Consistency = Atomic/Linearizable (tức thì, toàn cục).
   • Eventual Consistency không được tính là "C" trong CAP. Đừng nhầm lẫn!

3. Cân bằng C và A là "Software Trade-off":

   • CP hay AP được quyết định bởi dòng code bạn viết, bởi logic app bạn chọn (chờ đồng bộ hay ghi liều?).
   • Quyền lực nằm trong tay Developer, không phải DB Vendor.

4. Cái giá cắt cổ của Strong Consistency:

   • Muốn C, bạn phải trả bằng Latency (gấp đôi round-trip time) và Throughput (do phải xếp hàng xử lý).
   • Thận trọng khi dùng 2PC hay Paxos cho user-facing features.

5. Sự Mơ hồ của Lỗi Mạng (Network Ambiguity):

   • Hệ thống không bao giờ biết chắc node bên kia bị chết, bị chậm hay đứt mạng.
   • Timeout chính là "lời tiên tri" duy nhất mà bạn có để đoán lỗi và quyết định hy sinh.

Bảng Trade-offs Quan Trọng Nhất (CAP Decision Matrix)

Feature	CP (Consistency Priority)	AP (Availability Priority)
Mục tiêu chính	Bảo toàn Invariants (Tính toàn vẹn).	Tối ưu hóa Performance & Uptime.
Consistency Level	Strong (Atomic/Linearizable).	Eventual/Weak.
Hành vi khi P xảy ra	Trả về Lỗi 503 hoặc Timeout (Sacrifice A).	Trả về dữ liệu Stale hoặc Chấp nhận Write cục bộ (Sacrifice C).
Đặc điểm Performance	Low Throughput, High Latency (Do Serialization & Synchronous waits).	High Throughput, Low Latency (Do Local Write & Async replication).
Phù hợp Nghiệp vụ	Giao dịch tài chính, Kiểm kho (Inventory), Lock Servers, Leader Election.	Giỏ hàng, News Feed, DNS, Email, Streaming Media, Analytics.

Q&A.md

Phỏng vấn Giả lập: CAP & Consistency Patterns (Mock Interview)

Đây là 3 câu hỏi phỏng vấn được thiết kế để đánh giá tư duy hệ thống và khả năng ra quyết định kiến trúc của bạn về chủ đề CAP & Consistency Patterns, theo tiêu chuẩn của một Senior Software Engineer tại Google.

Bối cảnh: Xin chào, tôi là Lead Architect. Hôm nay chúng ta sẽ tập trung vào các trade-off trong hệ thống phân tán, cụ thể là CAP Theorem và các Consistency Patterns. Tôi kỳ vọng bạn không chỉ nhắc lại định nghĩa mà còn phân tích được ý nghĩa kinh doanh và chi phí vận hành của mỗi lựa chọn.

---

1. Level Junior (Kiến thức Cơ bản & Ứng dụng)

Câu hỏi: Trade-off Bắt buộc và Sự khác biệt Mềm dẻo (Software Trade-off)

"Trong hệ thống phân tán, sự cố mạng (network failures) là một định luật (fallacy). Điều này khiến Partition Tolerance (P) trở thành yêu cầu bắt buộc, buộc chúng ta phải thực hiện sự đánh đổi giữa Consistency (C) và Availability (A).

1. Hãy định nghĩa Consistency theo chuẩn Atomic/Linearizable và Availability theo ngữ cảnh của CAP.
2. Phân tích trade-off Software Trade-off giữa CP và AP. Hãy đưa ra hai ví dụ nghiệp vụ điển hình: một nơi bạn buộc phải chọn CP và một nơi bạn nên chọn AP để tối ưu hóa hiệu năng."

✅ Trả lời:

1. Định nghĩa Consistency và Availability

Consistency (Atomic/Linearizable):

• Mọi thao tác đọc (read) sau một thao tác ghi (write) thành công phải trả về giá trị mới nhất đó, bất kể client đọc từ node nào trong hệ thống.
• Nói cách khác: Hệ thống hoạt động như thể chỉ có một bản sao dữ liệu duy nhất (single replica illusion). Mọi thao tác đều có vẻ như xảy ra ngay lập tức tại một thời điểm duy nhất giữa lúc bắt đầu và kết thúc.
• Ví dụ: Nếu User A gửi tiền vào tài khoản lúc 10:00:00.000, thì User B đọc số dư lúc 10:00:00.001 phải thấy số tiền đã được cộng.

Availability (trong ngữ cảnh CAP):

• Mọi request gửi đến một node non-failing (không bị lỗi phần cứng) phải nhận được response trong một khoảng thời gian hợp lý (bounded time).
• Quan trọng: Response có thể là dữ liệu cũ (stale), nhưng không được là lỗi timeout hoặc error.
• Ví dụ: Khi user refresh newsfeed, họ luôn thấy một cái gì đó (có thể là feed cũ 5 giây), chứ không phải màn hình trắng hoặc lỗi 503.

2. Phân tích Trade-off CP vs. AP

Khía cạnh	CP (Consistency + Partition Tolerance)	AP (Availability + Partition Tolerance)
Khi Partition xảy ra	Hệ thống từ chối phục vụ (trả về lỗi 503/timeout) để đảm bảo không ai đọc được dữ liệu sai.	Hệ thống vẫn phục vụ (trả về 200 OK) nhưng dữ liệu có thể là bản cũ (stale).
Ưu tiên	Tính đúng đắn của dữ liệu (Data Integrity)	Trải nghiệm người dùng (User Experience/Uptime)
Chi phí ẩn	Latency cao (chờ đồng bộ), Throughput thấp. Client phải xử lý retry.	Cần cơ chế Conflict Resolution khi partition heal. Logic phức tạp ở tầng Application.

Ví dụ nghiệp vụ BẮT BUỘC chọn CP:

• Hệ thống chuyển tiền ngân hàng: Nếu User A chuyển 10 triệu cho User B, hệ thống không được phép trừ tiền A mà không cộng tiền B (hoặc ngược lại). Nếu có partition, thà trả về lỗi "Giao dịch thất bại, vui lòng thử lại" còn hơn để xảy ra tình trạng tiền "bốc hơi" hoặc "sinh sôi".
• Hệ thống quản lý tồn kho (Inventory): Nếu chỉ còn 1 sản phẩm, không thể để 2 người cùng mua thành công.

Ví dụ nghiệp vụ NÊN chọn AP:

• Giỏ hàng E-commerce (Shopping Cart): Nếu user thêm sản phẩm vào giỏ hàng, việc giỏ hàng hiển thị chậm vài giây không phải là thảm họa. Quan trọng là user không bị lỗi và có thể tiếp tục mua sắm. Khi checkout mới cần kiểm tra lại.
• Newsfeed/Timeline (Facebook, Twitter): User thà thấy feed cũ 5 giây còn hơn là màn hình trắng. Tính "real-time" là tương đối, không cần chính xác tuyệt đối.

---

2. Level Mid (Troubleshooting & Phân tích Lỗi)

Câu hỏi: Nhầm lẫn giữa Slow Machine và Network Partition

"Bạn đang vận hành một dịch vụ lưu trữ nhật ký giao dịch (transaction log) sử dụng chiến lược AP (Availability/Partition Tolerance) để đảm bảo thông lượng cao. Giao thức sao chép (replication) là bất đồng bộ (asynchronous).

Đột nhiên, đội ngũ giám sát (Observability team) cảnh báo rằng:

1. Độ trễ đọc (Read Latency P99) tăng vọt trên các node Replica (slave).
2. Users bắt đầu thấy dữ liệu cũ (stale data) kéo dài hơn 5 giây.
3. Tuy nhiên, không có lỗi timeout 503 nào xảy ra.

Trong mạng không đồng bộ (asynchronous network), chúng ta không thể phân biệt một máy bị hỏng, bị Partition hay chỉ đơn giản là bị chậm (slow machine).

Trong tình huống này, bạn nghi ngờ hệ thống đang gặp phải Replication Lag do Slow Machine (ví dụ: GC Pause) hay Partial Network Partition?

Hãy giải thích:

1. Lý do tại sao hệ thống AP vẫn duy trì Availability (không trả về lỗi 503) dù dữ liệu bị Stale.
2. Làm thế nào để các chỉ số Latency P99 và Replication Lag giúp bạn phân biệt giữa Slow Machine và Partition?
3. Biện pháp khắc phục (Mitigation) tức thời nào bạn sẽ áp dụng để giảm thiểu rủi ro dữ liệu Stale?"

✅ Trả lời:

1. Tại sao AP vẫn Available dù Stale?

Đây chính là bản chất của AP mode: Hệ thống ưu tiên trả về response nhanh chóng, bất kể dữ liệu có mới nhất hay không.

• Khi client gửi Read request đến Replica, Replica không cần hỏi Master xem dữ liệu có mới không. Nó chỉ đơn giản trả về những gì nó có trong local storage.
• Replication diễn ra bất đồng bộ (async): Master ghi xong trả về 200 OK ngay, sau đó mới cố gắng đẩy data sang Replica. Nếu Replica chậm nhận (do bất kỳ lý do gì), client đọc từ Replica sẽ thấy data cũ.
• Không có lỗi 503 vì Replica vẫn đang hoạt động bình thường (healthy), nó chỉ đơn giản là có dữ liệu chưa được cập nhật.

Insight: Đây là trade-off cố hữu của Eventual Consistency. Hệ thống đánh đổi tính "mới nhất" để lấy tốc độ và uptime.

2. Phân biệt Slow Machine vs. Partition bằng Metrics

Signal	Slow Machine (GC Pause)	Partial Network Partition
CPU/Memory của Replica	CPU spike cao (GC chiếm CPU) hoặc Memory pressure.	CPU/Memory bình thường.
Network I/O của Replica	Network I/O vẫn có traffic (đang cố gắng nhận data, chỉ là xử lý chậm).	Network I/O giảm đột ngột hoặc về 0 (không nhận được gói tin từ Master).
Replication Lag Pattern	Lag tăng đều đều (do xử lý chậm), sau đó tự hồi phục khi GC xong.	Lag tăng vô hạn (không bao giờ giảm) cho đến khi network được sửa.
Ping/Health Check Master → Replica	Thành công (network vẫn thông).	Thất bại hoặc timeout.
Log của Master	Không có lỗi gửi data.	Log báo lỗi Connection refused hoặc Timeout sending to replica.

Cách điều tra thực tế:

1. SSH vào Replica, chạy top hoặc htop xem CPU có bị một process nào chiếm hết không (thường là Java GC).
2. Chạy ping <master_ip> từ Replica để kiểm tra network connectivity.
3. Kiểm tra log replication của Master: Nếu thấy Connection timeout, đó là Partition. Nếu thấy Replication queue growing but sending OK, đó là Slow Machine.

3. Biện pháp Mitigation tức thời

Bước 1: Xác nhận và Cách ly (Identify & Isolate)

• Nếu là Slow Machine: Cách ly node đó khỏi Load Balancer pool (ngừng gửi traffic đọc đến node chậm). Chờ GC xong hoặc restart service.
• Nếu là Partition: Không cần làm gì với node đó (nó đã bị cô lập rồi). Tập trung đảm bảo các node healthy khác phục vụ traffic.

Bước 2: Tăng cường Read từ Master (Read-Your-Writes)

• Đối với các nghiệp vụ nhạy cảm (vừa write xong cần đọc lại ngay), định tuyến Read request đến Master thay vì Replica.
• Đây là chiến lược Sticky Session hoặc Read-Your-Writes Consistency.

Bước 3: Cảnh báo Bounded Staleness

• Nếu hệ thống có implement Bounded Staleness (như trong ProductionLab của chúng ta), endpoint Read nên trả về cảnh báo trong response: "Consistency_Status": "STALE (EXCEEDS_BOUND)".
• Tầng Application có thể dựa vào đó để hiển thị thông báo cho user: "Dữ liệu có thể chưa được cập nhật".

Bước 4: Dài hạn - Circuit Breaker

• Implement Circuit Breaker cho replication connection. Nếu Replica không nhận được data quá lâu (ví dụ > 10s), tự động đánh dấu nó là "degraded" và loại khỏi read pool.

---

3. Level Senior (System Design & Tinh chỉnh Kiến trúc)

Câu hỏi: Đánh đổi Hiệu năng khi Chuyển đổi Consistency

"Công ty của bạn đang sử dụng kiến trúc Master-Slave Replication (như App Engine Datastore đã từng chọn) để phục vụ một dịch vụ quan trọng, đạt được độ trễ ghi (Write Latency) thấp vì replication diễn ra bất đồng bộ. Tuy nhiên, rủi ro mất dữ liệu nhỏ (data loss window) và vấn đề Stale Reads là không chấp nhận được nữa.

Yêu cầu: Bạn phải nâng cấp hệ thống lên Strong Consistency (Atomic/Linearizable) và mở rộng sang 3 Data Centers (DC) để đạt khả năng phục hồi thảm họa.

1. Nếu bạn chọn triển khai giao thức Distributed Consensus (ví dụ: Paxos hoặc 2PC) để đạt Strong Consistency giữa 3 DC, hãy phân tích tác động trực tiếp và bắt buộc lên Write Latency. Cụ thể, tại sao độ trễ lại tăng gấp đôi (hoặc hơn) so với kiến trúc Master-Slave cũ?
2. Nếu yêu cầu kinh doanh buộc bạn phải duy trì Strong Consistency nhưng không được vượt quá Latency P99 hiện tại (ví dụ: 50ms), bạn sẽ đề xuất chiến lược kiến trúc nào để cân bằng C và Latency? (Gợi ý: Cân nhắc các kỹ thuật như Sharding hoặc giới hạn phạm vi giao dịch).
3. Làm thế nào việc sử dụng Entity Groups trong sharding có thể giúp bạn đạt được tính nguyên tử (atomic transaction) mà không cần Paxos/2PC trên toàn bộ hệ thống?"

✅ Trả lời:

1. Tại sao Write Latency tăng gấp đôi (hoặc hơn) với Paxos/2PC?

Với Master-Slave Async (Kiến trúc cũ):

Client → Master (Write local) → Return 200 OK
         ↓ (Async, không chờ)
       Slave

• Latency = 1 Round Trip (Client → Master → Client).
• Master ghi xong local disk là trả về ngay. Replication diễn ra ngầm sau đó.

Với Paxos/2PC (Kiến trúc mới - Strong Consistency):

Client → Leader (Propose)
         ↓ (Phase 1: Prepare)
       DC1, DC2, DC3 (Gửi prepare request)
         ↓ (Chờ Majority ACK)
       Leader (Phase 2: Accept)
         ↓ (Gửi accept request)
       DC1, DC2, DC3 (Gửi accept ACK)
         ↓ (Chờ Majority ACK)
       Leader → Return 200 OK to Client

• Latency = 2 Round Trips (tối thiểu, thực tế có thể hơn).
  • Round Trip 1: Leader → Followers (Prepare) → Leader.
  • Round Trip 2: Leader → Followers (Accept) → Leader.
• Nếu 3 DC nằm ở các vùng địa lý khác nhau (ví dụ: US, EU, Asia), mỗi round trip có thể mất 50-100ms. Tổng latency: 100-200ms thay vì 10-20ms như trước.

Lý do sâu xa:

• Strong Consistency bắt buộc hệ thống phải chờ xác nhận từ majority (đa số) trước khi trả về thành công.
• Đây là cái giá không thể tránh khỏi của CAP: Muốn C (Consistency), phải hy sinh Latency/Throughput.

2. Chiến lược cân bằng C và Latency (Giữ P99 < 50ms)

Chiến lược 1: Geo-Colocation (Đặt DC gần nhau)

• Thay vì đặt 3 DC ở 3 châu lục, đặt cả 3 DC trong cùng một Region (ví dụ: 3 Availability Zones trong AWS us-east-1).
• Latency giữa các AZ trong cùng region: < 2ms.
• Latency 2 round trips: < 4ms → Đạt P99 < 50ms dễ dàng.
• Trade-off: Giảm khả năng DR (Disaster Recovery) vì cả 3 DC đều nằm trong một region. Nếu cả region bị sự cố (hiếm nhưng có thể xảy ra), mất toàn bộ.

Chiến lược 2: Sharding + Local Consensus (Entity Groups)

• Không chạy Paxos trên toàn bộ dataset, mà chỉ chạy Paxos trong phạm vi một Shard (Entity Group).
• Mỗi Shard được đặt trong một cụm 3 nodes gần nhau (cùng region hoặc cùng DC).
• Transaction chỉ cần consensus trong phạm vi Shard đó, không cần đợi các Shard khác.
• Ví dụ: User A ở Việt Nam, data của User A nằm trong Shard "VN-Shard" được replicate trong 3 nodes ở Singapore. Latency consensus: ~5-10ms.

Chiến lược 3: Hierarchical Consensus

• Kết hợp Sync và Async:
  • Intra-Region: Sync replication (Paxos/Raft) giữa 3 AZ trong cùng region. → Strong Consistency.
  • Cross-Region: Async replication giữa các Region. → Eventual Consistency cho DR.
• User được phục vụ bởi Region gần nhất. Nếu Region đó sập, failover sang Region khác (chấp nhận mất một ít data trong data loss window).

3. Entity Groups và Atomic Transactions không cần Global Paxos

Khái niệm Entity Group:

• Entity Group là một nhóm các entities (records) có quan hệ logic với nhau và thường được truy cập cùng nhau.
• Ví dụ: Một Order và tất cả OrderItems của nó thuộc cùng một Entity Group. Một User và UserProfile, UserSettings của họ thuộc cùng một Entity Group.

Cách hoạt động:

1. Sharding theo Entity Group: Toàn bộ data của một Entity Group được lưu trên cùng một Shard (cùng một cụm Paxos).
2. Transaction trong Entity Group: Vì tất cả data liên quan nằm trên cùng một Shard, transaction chỉ cần local Paxos trong Shard đó. Không cần 2PC/Paxos xuyên Shard.
3. Transaction xuyên Entity Group: Nếu cần (hiếm khi), sử dụng các pattern như Saga hoặc chấp nhận Eventual Consistency.

Ví dụ cụ thể (E-commerce):

Entity Group: Order #12345
├── Order { id: 12345, user_id: 100, total: 500k }
├── OrderItem { order_id: 12345, product_id: A, qty: 2 }
└── OrderItem { order_id: 12345, product_id: B, qty: 1 }

• Khi user đặt hàng, cần tạo 1 Order + 2 OrderItems atomically.
• Vì cả 3 records thuộc cùng Entity Group (cùng Shard), chỉ cần một local transaction. Không cần distributed transaction.

Tại sao cách này hiệu quả?

• Giảm phạm vi coordination: Thay vì phải đồng thuận trên toàn bộ 3 DC x tất cả data, chỉ cần đồng thuận trong phạm vi 1 Shard (3 nodes gần nhau).
• Horizontal Scaling: Thêm Shards để tăng throughput. Mỗi Shard có thể xử lý ~10k writes/sec nếu được tối ưu.
• Đây chính xác là cách Google App Engine Datastore hoạt động: Strong Consistency trong Entity Group, Eventual Consistency giữa các Entity Groups.

Kết luận Senior-level: Bí quyết không phải là "chọn C hay A", mà là thu hẹp phạm vi cần Strong Consistency xuống mức nhỏ nhất có thể (Entity Group), và chấp nhận Eventual Consistency cho phần còn lại. Đây là trade-off thực tế mà các hệ thống lớn như Spanner, CockroachDB, và Datastore đều áp dụng.