Khi nào thì Monolith bắt đầu “vỡ trận"

App lag, chắc Monolith to quá, tách microservice đi anh!

– Nhưng hóa ra, chỉ cần index DB là xong!

Một công ty logistics Việt Nam dùng Monolith PHP, xử lý 20k đơn hàng/ngày. Team phàn nàn “chậm”, đòi tách microservice, nhưng audit thấy lag do query DB thiếu index. Monolith chưa “vỡ”, nhưng team đã muốn “phá nhà”!

Dấu hiệu Monolith “vỡ”

Dấu hiệu thật sự cần tách:  

• Team block nhau: Dev team Order chờ team User merge code, PR kẹt hàng tuần.  
• Code conflict: Một thay đổi nhỏ ở module Product làm hỏng Payment.  
• Khó scale: Cần scale API Order, nhưng cả app phải scale cùng.  
• PR phức tạp: PR 1000 dòng, review mệt, dễ lọt bug.

Sai lầm: Đổ lỗi cho Monolith khi vấn đề là thiếu index DB, không cache, hoặc code kém tối ưu.

Ví dụ thực tế: Một app giao hàng Việt Nam mà tôi có cơ hội tham gia audit, Monolith Laravel 500k dòng code, 30 dev làm việc. PR merge chậm vì conflict liên module, deploy toàn app mất 20 phút. 

Tôi tư vấn: cần tách Order Service để scale riêng.

Góc nhìn CTO

Monolith “vỡ” không phải vì nó “dở”, mà vì team và sản phẩm đã lớn. Đừng tách chỉ vì lag, hãy audit kỹ: DB, cache, code trước khi “phá nhà”.

Checklist đánh giá Monolith “vỡ”:  

• PR trung bình >500 dòng hoặc conflict >3 lần/tuần.  
• Deploy toàn app mất >15 phút.  
• Team >20 dev, chia thành 2+ domain.  
• Một module cần scale riêng (VD: Order cần 10 instance, User chỉ cần 2).

🎯 Tóm lại: Monolith chỉ “vỡ” khi team block nhau hoặc scale khó. Audit kỹ trước khi tách, đừng để lag “dắt mũi” chạy theo microservice!