System DesignCAP bị hiểu sai ở chỗ nhiều người phát biểu "chọn 2 trong 3". Thực tế phân vùng mạng là sự kiện xảy ra chứ không phải lựa chọn, nên câu đúng là: khi có phân vùng (P), phải chọn giữa tính sẵn sàng (A) và tính nhất quán (C). Khi mạng bình thường, không phải hy sinh gì cả. Ngoài ra "C" trong CAP là linearizability — chặt hơn chữ C trong ACID, hai thứ khác nhau dù trùng tên.
PACELC vá phần CAP bỏ trống: nếu có phân vùng (P) thì chọn A hay C; else (E), khi hệ thống chạy bình thường, vẫn phải chọn giữa độ trễ (L) và tính nhất quán (C).
Vế sau mới là vế gặp hằng ngày. Phân vùng mạng hiếm; còn đánh đổi latency với consistency thì tồn tại trong mọi request:
- Muốn đọc luôn thấy dữ liệu mới nhất → phải đọc từ primary hoặc chờ quorum xác nhận → độ trễ cao hơn, nhất là khi replica ở vùng khác.
- Chấp nhận đọc từ replica gần nhất → nhanh hơn nhiều nhưng có thể thấy dữ liệu cũ.
Phân loại theo PACELC: Cassandra và DynamoDB (mặc định) là PA/EL — ưu tiên sẵn sàng và độ trễ. Spanner là PC/EC — giữ nhất quán và trả giá bằng độ trễ commit. MongoDB tùy cấu hình write concern và read preference.
Khi phỏng vấn, dùng PACELC để nói rõ hơn CAP: "luồng thanh toán em chọn EC (đọc từ primary), còn luồng hiển thị số lượt thích em chọn EL vì trễ vài giây không ảnh hưởng nghiệp vụ".