Microservice là gì và tại sao ai cũng muốn chạy theo nó?

Monolith của em lag rồi, tách microservice cho xịn đi anh!

– Nhưng tách xong, cả team debug đến… khuya.

Một công ty fintech Việt Nam, sau 2 năm dùng Monolith, quyết định tách thành microservice vì “team lớn, Monolith không scale nổi”. Kết quả? API User gọi API Payment, nhưng network latency làm khách hàng chờ 5 giây. Microservice nghe xịn, nhưng không phải phép màu.

Microservice là gì?

Microservice là tập hợp các service nhỏ, độc lập, giao tiếp qua API (REST, gRPC, hoặc message queue). Mỗi service có DB riêng, deploy riêng, ví dụ: User Service (Node.js, MongoDB), Payment Service (Python, PostgreSQL).

Lý do adopt:  

• Scale team: Team User làm việc độc lập với team Payment, không giẫm chân nhau.  
• Deploy riêng: Update User Service không ảnh hưởng Payment.  
• Tech stack linh hoạt: Dùng Golang cho performance-critical, Python cho ML.

Nhược điểm:  

• Complexity tăng: Quản lý 10 service, 10 DB, 10 pipeline.  
• Debug khó: Lỗi không nằm trong 1 stack trace nữa, cần tracing.  
• Chi phí vận hành: Kubernetes, monitoring, logging tốn tiền và công sức.

Ví dụ thực tế: App ví điện tử Việt Nam tôi tham gia audit tách User, Payment, Notification thành microservice. Team scale từ 10 lên 50 dev, nhưng phải đầu tư Kubernetes, ELK, và học cách debug distributed system.

Góc nhìn CTO

Microservice là “con dao hai lưỡi”. Chỉ adopt khi team đủ lớn (>20 dev) hoặc Monolith thực sự gây tắc nghẽn. Đừng chạy theo hype, vì “xịn” không có nghĩa là “phù hợp”.

Checklist trước khi tách microservice:  

• Team có trên 15 dev, chia theo domain.  
• Monolith đã có boundary rõ (module, layer).  
• Có DevOps engineer và CI/CD pipeline.  
• Sẵn sàng đầu tư monitoring (Prometheus, Jaeger).

🎯 Tóm lại: Microservice giúp scale, nhưng cũng dễ làm team “toang” nếu không chuẩn bị. Làm Monolith tốt trước, rồi tách dần, đừng vội “đua đòi”!