Quản lý dữ liệu khi tách service — Shared DB là tử thần

Order Service gọi User Service, nhưng cả hai share DB, xong… prod sập, anh ơi!

Một app TMĐT Việt Nam tôi đã nhắc trong bài trước tách Order Service, nhưng để cả Order và User truy cập chung MySQL. Kết quả? User Service update schema, Order Service crash vì query sai. Shared DB là “tử thần” trong microservice.

Tại sao shared DB nguy hiểm?

• Coupling ngầm: Service thay đổi schema, làm ảnh hưởng service khác.  
• Khó scale: DB chung thành bottleneck, không scale riêng được.  
• Debug đau đầu: Lỗi DB không rõ từ service nào.

Pattern giải quyết:  

• DB-per-service: Mỗi service có DB riêng (VD: Order dùng PostgreSQL, User dùng MongoDB).  
• Event sourcing: Ghi sự kiện (VD: OrderCreated) vào Kafka, service khác consume.  
• Saga/Orchestration: Điều phối giao dịch phân tán (VD: Order đặt hàng → Payment xác nhận).

Ví dụ thực tế: App TMĐT tách Order Service:  

• Order Service có PostgreSQL riêng, chỉ lưu user_id.  
• User Service expose API /users/{id} để Order lấy thông tin.  
• Dùng Kafka để gửi event OrderPlaced cho Notification Service.

Góc nhìn CTO

Shared DB là “cạm bẫy” trong microservice. Tách DB sớm, dùng event-driven để giảm coupling, nhưng cần chuẩn bị tinh thần cho complexity của distributed data.

Checklist quản lý dữ liệu:  

• Mỗi service có DB riêng, chỉ liên kết qua ID.  
• Dùng API hoặc event để giao tiếp giữa service.  
• Áp dụng Saga/Orchestration cho giao dịch phân tán.  
• Monitor latency và consistency giữa DB.

🎯 Tóm lại: Shared DB là “tử thần” của microservice. Tách DB, dùng event sourcing, để service không “đá nhau” trong prod!