Khi tư vấn kiến trúc cho khách hàng enterprise, câu hỏi đầu tiên gần như luôn là: "Chúng tôi nên đi microservices ngay từ đầu chứ?" Câu trả lời ngắn của chúng tôi là không. Câu trả lời dài là bài viết này.
Cái giá ẩn của microservices sớm
Trong dự án PROPEL HRM năm 2024, đội ban đầu đã muốn chia ngay 12 bounded context thành 12 service riêng. Chúng tôi đã thuyết phục họ gộp lại thành một modular monolith. Quyết định đó tiết kiệm khoảng bốn tháng setup hạ tầng, hai engineer DevOps full-time, và quan trọng hơn — cho phép team tập trung vào nghiệp vụ payroll thay vì debug service mesh trong nửa năm đầu.
Khi nào nên tách?
Chúng tôi đặt ra ba điều kiện để chuyển một module thành service riêng: (1) module có quy mô traffic khác biệt rõ rệt — ví dụ module Notifications xử lý 100x request so với phần còn lại, (2) module cần deploy độc lập — thường là khi team sở hữu nó phát triển trên 8-10 người, (3) module có yêu cầu compliance hoặc bảo mật khác biệt — ví dụ module Payment cần PCI-DSS scope hẹp.
Pattern thực tế: ranh giới rõ, deploy đơn
Trong code thực, chúng tôi enforce ranh giới module bằng ArchUnit (Java) hoặc Conventional Commits + custom linters (.NET, Node). Mỗi module có folder riêng, không được import trực tiếp class của module khác — phải đi qua interface công khai. Database schema cũng được tách thành các schema PostgreSQL khác nhau, mỗi module chỉ có quyền truy cập schema của mình. Khi cần tách thành service, chỉ việc thay interface thành HTTP client.
Kết luận thực dụng
Modular monolith không phải là 'monolith ngụy trang' — nó là một cam kết thiết kế nghiêm túc với chi phí vận hành thấp hơn nhiều so với microservices. Hãy bắt đầu ở đây. Nếu sau 18 tháng bạn vẫn không có nhu cầu tách, có lẽ bạn không bao giờ cần.
