Monorepo vs Polyrepo trong hệ thống Microservice

Anh ơi, tụi em để 10 service trong một repo cho tiện, giờ PR dài cả cây số, làm sao đây?

Một công ty fintech Việt Nam, sau khi tách microservice, nhét hết 10 service (Auth, Order, Payment, Notification...) vào một monorepo. 

Kết quả? PR merge chậm như “rùa bò”, build cả 10 service dù chỉ sửa một dòng CSS. Team khác thì dùng polyrepo, mỗi service một repo, nhưng lại đau đầu vì sync config giữa các repo. 

Monorepo vs Polyrepo: Định nghĩa

• Monorepo: Tất cả microservice nằm trong một Git repository, thường chia folder theo service (VD: /services/auth, /services/order).  
• Polyrepo: Mỗi microservice có repository riêng, độc lập về code, CI/CD, và deploy.

Ưu và nhược điểm

Monorepo

• Ưu điểm:  
• Dễ quản lý codebase: Một repo, clone một lần, thấy hết code.  
• Tái sử dụng code: Dùng chung library, config, hoặc script build (VD: share eslint config).  
• Dễ đồng bộ: Thay đổi API contract (VD: update /auth/login) được review trong cùng PR.  
• Onboarding nhanh: Dev mới chỉ cần clone một repo, không phải “săn” 10 repo.
• Nhược điểm:  
• Build chậm: Sửa một service, CI/CD build cả 10 service, mất 20 phút.  
• PR phức tạp: PR có thể lên đến 1000 dòng nếu nhiều service thay đổi cùng lúc.  
• Dependency hell: Các service dùng version khác nhau của cùng package (VD: [email protected] vs [email protected]).
• Ví dụ thực tế: Một app ví điện tử Việt Nam dùng monorepo, chứa 8 service trong /services. Team 10 dev làm việc dễ dàng, nhưng khi scale lên 30 dev, CI/CD build tốn 25 phút dù chỉ sửa Notification Service.

Polyrepo

• Ưu điểm:  
• Độc lập: Mỗi service có CI/CD riêng, build nhanh (5 phút/service).  
• Team autonomy: Team Auth deploy không ảnh hưởng team Order.  
• Isolation tốt: Service A lỗi không làm hỏng CI của Service B.
• Nhược điểm:  
• Sync khó: API contract thay đổi cần update nhiều repo, dễ miss.  
• Quản lý phức tạp: Dev phải clone 10 repo, config môi trường riêng.  
• Overhead DevOps: Mỗi repo cần pipeline riêng, tốn công setup.
• Ví dụ thực tế: Một sàn TMĐT Việt Nam dùng polyrepo cho 5 service. Team Order deploy nhanh, nhưng khi Auth Service đổi schema API, Order Service crash vì không sync kịp.

Tools hỗ trợ Monorepo

• Nx: Quản lý build, cache thông minh, chỉ build service bị thay đổi.  
• Turborepo: Tăng tốc CI/CD với caching và parallel build.  
• Lerna: Quản lý multi-package trong monorepo, hỗ trợ versioning.  
• Bazel: Build system mạnh mẽ cho monorepo lớn, nhưng setup phức tạp.

Code mẫu: Nx monorepo setup

npx create-nx-workspace my-microservices

cd my-microservices

nx g @nrwl/node:app auth-service

nx g @nrwl/node:app order-service

Monorepo hay polyrepo, chọn cái nào để không “khóc thầm” lúc nửa đêm?

• Team nhỏ (<15 dev): Dùng monorepo cho dễ setup, quản lý. Dùng Nx/Turborepo để tối ưu build.  
• Doanh nghiệp lớn (>30 dev): Polyrepo để team độc lập, nhưng cần API contract rõ ràng (OpenAPI, gRPC schema).  
• Hybrid: Monorepo cho shared library, polyrepo cho service độc lập.

Góc nhìn CTO

Monorepo hay polyrepo không chỉ là chuyện code, mà là chuyện tổ chức team. Monorepo hợp với startup nhỏ, cần tốc độ và đồng bộ. Polyrepo hợp với team lớn, cần autonomy. Đừng chọn chỉ vì “nghe xịn”, hãy chọn dựa trên team size và DevOps maturity.

Checklist chọn repo strategy:  

• Team <15 dev → Monorepo, dùng Nx/Turborepo.  
• Team >30 dev → Polyrepo, document API contract.  
• Có DevOps engineer để setup CI/CD cho từng repo.  
• Dùng tool (Nx, Lerna) để quản lý monorepo hiệu quả.  
• Audit định kỳ dependency và build time.

🎯 Tóm lại: Monorepo hay polyrepo là “trận chiến” giữa đồng bộ và độc lập. Chọn đúng theo team size, đừng để PR dài như “tờ sớ” hay sync API thành “trò chơi đoán chữ”! full-width