Sự thật khó chịu về Microservices
Hầu hết các startup và doanh nghiệp vừa không cần microservices. Họ cần một monolith được viết tốt. Microservices giải quyết vấn đề tổ chức (nhiều team làm việc độc lập) nhiều hơn vấn đề kỹ thuật.
Khi nào Monolith là đúng
✅ Team < 30 kỹ sư
✅ Sản phẩm chưa tìm được product-market fit
✅ Domain chưa được hiểu rõ
✅ Tốc độ iteration quan trọng hơn scale
Khi nào chuyển sang Microservices
✅ Các phần khác nhau của hệ thống cần scale độc lập
✅ Team lớn hơn 50 người với nhiều nhóm độc lập
✅ Yêu cầu deployment frequency khác nhau giữa các module
✅ Công nghệ khác nhau phù hợp cho từng domain
Strangler Fig Pattern: Di chuyển an toàn
Đừng bao giờ viết lại từ đầu. Dùng Strangler Fig Pattern:
1. Đặt proxy/API gateway trước monolith
2. Tách từng tính năng nhỏ ra service độc lập
3. Route traffic dần từ monolith sang service mới
4. Xóa code cũ sau khi service mới ổn định
Distributed Monolith: Cái bẫy phổ biến nhất
Nếu các service của bạn không thể deploy độc lập, không có bounded context rõ ràng, và call nhau đồng bộ theo chuỗi – bạn có một distributed monolith, tệ hơn cả monolith lẫn microservices.
Khuyến nghị
Bắt đầu với modular monolith. Tách service khi bạn CÓ BẰNG CHỨNG cụ thể rằng cần làm vậy, không phải vì nghe có vẻ hay.