Xuyên các service bạn thường đánh đổi tính nhất quán mạnh (strong) lấy tính nhất quán eventual, và dựa vào CQRS và event sourcing để làm cho điều đó khả thi và đúng đắn.
Sau một thay đổi, các bản sao hội tụ "sớm thôi" chứ không phải tức thì. Chấp nhận được với hầu hết luồng nghiệp vụ (số lượng tồn kho có thể trễ một giây), không chấp nhận được với một số (kiểm tra số dư ngân hàng).
Tách write model khỏi một hoặc nhiều read model.
Command ─▶ Write model ─phát event─▶ [ Read model ]
Query ──────────────────────────────▶ Read model (phi chuẩn hóa, nhanh)
Đọc mở rộng và định hình lại độc lập với ghi; read model được cập nhật từ các event, nên nó eventual consistency.
Lưu chuỗi các event làm nguồn sự thật, không chỉ trạng thái hiện tại. Trạng thái hiện tại là một phép gập (fold) trên các event.
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ trạng thái: balance = 70
(event là bất biến + chỉ ghi nối đuôi → audit đầy đủ + du hành thời gian)
| Kỹ thuật | Lợi ích | Chi phí |
|---|---|---|
| Eventual consistency | Tính khả dụng, mở rộng | Đọc dữ liệu cũ, xung đột |
| CQRS | Mở rộng đọc/ghi | Hai mô hình phải đồng bộ |
| Event sourcing | Audit, phát lại, lịch sử | Tiến hóa schema/event, phức tạp |
Đừng áp dụng event sourcing ở mọi nơi — nó mạnh nhưng nặng. Dùng nó ở nơi audit/lịch sử thực sự quan trọng.
Các hệ phân tán không thể có đồng thời cả tính nhất quán mạnh, tính khả dụng, và khả năng chịu phân vùng, nên thiết kế ở mức senior là về việc chọn nơi eventual consistency có thể chấp nhận được.
CQRS và event sourcing cho bạn công cụ để làm eventual consistency trở nên đáng tin cậy và có thể audit — nhưng mỗi cái thêm độ phức tạp thực sự, nên hãy áp dụng có chọn lọc, không phải mặc định.