System DesignDatabase per service: mỗi service sở hữu schema của mình, service khác chỉ truy cập qua API, không đọc/ghi thẳng bảng.
Lý do:
- Chia sẻ database làm hai service dính chặt vào cấu trúc bảng. Đổi tên một cột là phải phối hợp deploy nhiều team — đúng thứ mà microservice muốn tránh.
- Mỗi service tự chọn kiểu lưu trữ phù hợp (quan hệ, document, search index).
- Sự cố dữ liệu bị khoanh vùng trong một service.
Hệ quả — mất JOIN và mất transaction xuyên service. Cách xử lý:
- Truy vấn cần dữ liệu nhiều service: gọi song song từng service rồi ghép ở tầng trên (API composition), hoặc dựng sẵn một read model tổng hợp cập nhật bằng event.
- Ghi cần nhiều service: dùng saga — chuỗi transaction cục bộ, mỗi bước có bước bù trừ khi lỗi.
- Báo cáo / analytics: không truy vấn thẳng DB nghiệp vụ. Đẩy dữ liệu từ các service về một kho phân tích (data warehouse) bằng CDC hoặc event, rồi JOIN thoải mái ở đó.
Cần chấp nhận rằng dữ liệu tổng hợp là eventually consistent — trễ vài trăm ms đến vài giây.