Bài học thất bại từ việc microservice hóa quá sớm

Microservice là tương lai, làm luôn đi anh!

– Kết quả? Team 4 dev, 18 service, debug đến khuya, MVP vẫn chưa ra mắt.

Một startup non-tech Việt Nam, làm app đặt lịch bác sĩ, thuê team outsource tách microservice ngay từ MVP. 

Kết quả? 18 service (Auth, Booking, Payment, Notification...), nhưng code thiếu best practice, service gọi nhau vòng tròn, debug như “đi tìm kho báu”. Sau 6 tháng, app vẫn chưa chạy ổn, trong khi đối thủ dùng Monolith ra mắt trong 2 tháng.

Case thật: Thảm họa microservice hóa sớm

Context

• Team: 4 dev (2 backend, 1 frontend, 1 outsource DevOps).  
• Hệ thống: 18 microservice (Node.js, Python), chạy trên Kubernetes, dùng REST và RabbitMQ.  
• Vấn đề:  
• Code thiếu best practice: Không unit test, không API contract, service gọi nhau vòng tròn (Booking → Payment → Booking).  
• Debug đau đầu: Lỗi ở Booking Service, phải trace qua 5 service, không có tracing tool.  
• Cấu hình lộn xộn: Mỗi service có .env riêng, không ai quản lý toàn cục.  
• DevOps yếu: Team outsource setup Kubernetes, nhưng không ai hiểu cách scale pod.

Hệ quả 

• MVP chậm: 6 tháng chưa ra mắt, đối thủ chiếm thị trường.  
• Chi phí cao: Cloud bill tăng vì Kubernetes và RabbitMQ ngốn tài nguyên.  
• Team kiệt sức: Debug distributed system làm dev “toang” tinh thần.

Các vấn đề phổ biến khi microservice hóa sớm

1. Team chưa quen CI/CD: Pipeline mỗi service phức tạp, build fail liên tục vì thiếu test.  
2. Monitoring/logging yếu: Không dùng ELK/Jaeger, không biết service chết vì sao.  
3. Thiếu BE lead: Không ai đủ kinh nghiệm maintain 18 service, mỗi service cần ít nhất 1 dev “chăm sóc”.  
4. Over-engineering: Startup nhỏ không cần 18 service, Monolith đủ đáp ứng 1000 user/ngày.

Ví dụ thực tế: Startup trên tách Booking Service, nhưng không có healthcheck, service chết lặng lẽ. Log phân tán, không trace_id, team mất 3 ngày tìm bug do RabbitMQ queue tắc.

Giải pháp: Modular Monolith trước

• Modular Monolith: Tách boundary trong codebase (VD: /app/Booking, /app/Payment), deploy chung, dễ debug.  
• CI/CD đơn giản: Một pipeline cho Monolith, dùng GitHub Actions.  
• Monitoring cơ bản: Dùng CloudWatch hoặc Loki cho log, Prometheus cho metric.  
• Tách dần: Khi team >15 dev, tách service ít phụ thuộc (VD: Notification).

Code mẫu: Modular Monolith (Laravel)

// app/Booking/Services/BookingService.php

namespace App\Booking\Services;

class BookingService {

    public function createBooking($userId, $doctorId) {

        // Logic đặt lịch

        return Booking::create(['user_id' => $userId, 'doctor_id' => $doctorId]);

    }

}

Góc nhìn CTO

Microservice không phải là “phép màu” mà là mô hình tổ chức team. Team nhỏ (<10 dev), chưa có DevOps, cứ làm Modular Monolith cho lành. Tách microservice khi team đủ mạnh và Monolith thực sự “vỡ”. Đừng để hype biến hệ thống thành “phim kinh dị”!

Checklist tránh microservice hóa sớm:  

• Team <10 dev → Modular Monolith, focus MVP.  
• Có DevOps engineer và CI/CD pipeline trước khi tách.  
• Setup monitoring (ELK, Jaeger) và logging chuẩn JSON.  
• Tách service ít phụ thuộc trước (VD: Notification).  
• Document API contract và schema DB rõ ràng.

🎯 Tóm lại: Microservice hóa sớm với team 5 người là “tự đào hố chôn mình”. Làm Modular Monolith trước, tách dần khi team đủ mạnh, để không biến prod thành “trò chơi con mực”! full-width