Định lý CAP: Nghệ Thuật Đánh Đổi Trong Hệ Thống Phân Tán

TL;DR
Trong mọi hệ thống phân tán, mạng internet luôn có thể xảy ra lỗi (Partition). Khi đó, Product Manager buộc phải chọn một trong hai: giữ cho hệ thống tiếp tục hoạt động nhưng chấp nhận dữ liệu có thể bị cũ (Availability), hoặc ngừng phục vụ người dùng để bảo vệ tính chính xác tuyệt đối của dữ liệu (Consistency). Không bao giờ có cả ba.
1. CAP Theorem là gì? (Định nghĩa & Thành phần)
Định lý CAP (do nhà khoa học máy tính Eric Brewer đưa ra) là một nguyên lý tối quan trọng trong System Design. Nó phát biểu rằng một hệ thống phân tán (distributed data store) chỉ có thể cung cấp tối đa hai trong ba sự đảm bảo sau:
- Consistency (Tính nhất quán - C): Mọi client khi đọc dữ liệu vào cùng một thời điểm đều nhận được dữ liệu mới nhất (hoặc nhận được thông báo lỗi). Dữ liệu đồng nhất trên tất cả các node.
- Availability (Tính khả dụng - A): Mọi yêu cầu (request) gửi đến một node đang hoạt động đều nhận được phản hồi thành công (không bị lỗi hoặc timeout), nhưng không đảm bảo đó là dữ liệu mới nhất.
- Partition Tolerance (Khả năng chịu lỗi chia cắt - P): Hệ thống vẫn tiếp tục hoạt động bất chấp việc mạng lưới kết nối giữa các node bị đứt gãy hoặc mất gói tin.
Bản chất của vấn đề: Trong thế giới thực, lỗi mạng là điều hiển nhiên (Network Partitions). Do đó, (P) là yếu tố bắt buộc phải có. Cuộc chiến thực sự của Product Team luôn là sự đánh đổi giữa C và A.
2. Khi nào nên áp dụng? (Use Cases & Target Audience)
Định lý CAP không chỉ dành cho kỹ sư. Product Manager và BA cần sử dụng framework này để định hình Product Requirements khi:
- Quyết định chọn Database: Hiểu lý do đội Tech chọn RDBMS (SQL) hay NoSQL (Cassandra, MongoDB, DynamoDB) cho từng tính năng.
- Định nghĩa SLA (Service Level Agreement): Cân nhắc xem hệ thống được phép "down" bao nhiêu phút mỗi tháng, hay phải duy trì uptime 99.99% bất chấp dữ liệu bị "lag".
- Xây dựng Fallback Mechanisms (Cơ chế dự phòng): Thiết kế luồng UX/UI khi hệ thống mất đồng bộ (ví dụ: thông báo "Dữ liệu đang được cập nhật").
3. Hướng dẫn từng bước (Step-by-Step / Deep Dive)
Để áp dụng tư duy CAP vào việc ra quyết định Product, hãy đi qua 4 bước đánh giá:
Bước 1: Chấp nhận "P" (Partition) là hằng số Đừng bao giờ yêu cầu team Tech xây dựng một hệ thống phân tán "không bao giờ rớt mạng". Hãy giả định rằng các server chắc chắn sẽ có lúc không thể nói chuyện với nhau.
Coming Soon
Bộ câu hỏi thực hành cho kỹ thuật này đang được chuyên gia xây dựng.