Khi không có database dùng chung, bạn không thể dùng JOIN xuyên service hay transaction ACID đơn nhất. Bạn tổng hợp dữ liệu và giữ nhất quán bằng API composition, replication/CQRS read model, và event.
— một bộ điều phối gọi từng service và ghép kết quả lại:
// dựng một view của order từ ba service
const order = await ordersApi.get(orderId);
const customer = await usersApi.get(order.customerId); // service riêng
const shipment = await shippingApi.get(orderId);
return { ...order, customer, shipment }; // ghép trong bộ nhớ
Đối với các truy vấn nặng, hãy duy trì một read model (CQRS): một service đăng ký các event và dựng một bản sao cục bộ đã phi chuẩn hóa mà nó có thể truy vấn trực tiếp.
Orders ─event→ ┐
Users ─event→ ├─▶ [ Order-View service dựng bảng có thể truy vấn của riêng nó ]
Shipping ─event→ ┘
Dùng pattern Saga — một chuỗi các transaction cục bộ với các hành động bù trừ — thay vì một distributed transaction.
| Cách tiếp cận | Ưu | Nhược |
|---|---|---|
| API composition | Luôn mới | Độ trễ, fan-out, dễ vỡ |
| Read model nhân bản | Đọc nhanh | Eventual consistency |
| Saga | Không cần 2PC | Phức tạp, cần bù trừ |
Đừng "chỉ là" dùng chung một bảng để dễ join — điều đó gắn kết lại các service. Hãy chấp nhận eventual consistency ở nơi nghiệp vụ cho phép.
Quản lý dữ liệu là nơi microservices thực sự trở nên khó, vì các công cụ dễ dùng (join, transaction) đã không còn theo thiết kế.
Hiểu composition, read model, và saga là điều cho phép bạn giữ các service độc lập mà không mất tính đúng đắn.