Microservice 12 người -> 24 service

Một startup giao đồ ăn Việt Nam, team 12 dev (6 backend, 4 frontend, 2 DevOps), quyết tâm tách 24 microservice (Auth, Order, Delivery, Payment, Notification...). Kết quả? Service gọi nhau như “vòng xoay Cộng Hòa”, bug fix mất 2 ngày, demo cho nhà đầu tư crash vì dependency lằng nhằng. Team chỉ muốn quay lại thời Monolith “êm đềm”!

Case thực tế: Microservice “nhỏ quá hóa khổ”

• Context: App giao đồ ăn, 5000 đơn/ngày, team 12 dev.
• Quyết định sai: Tách 24 microservice ngay từ MVP, mỗi chức năng nhỏ (VD: gửi SMS, tính phí giao hàng) thành một service.
• Vấn đề:
• Dependency vòng tròn: Order → Delivery → Payment → Order, latency tăng 3s/call.
• Debug đau đầu: Bug ở Order Service, phải trace qua 5 service, không có tracing tool.
• Downtime thường xuyên: Một service chết (VD: Notification), kéo theo API Gateway crash.

Hậu quả:

• Bug fix chậm: Mỗi bug mất 2 ngày trace, velocity giảm 50%.
• Demo fail: Trình bày cho nhà đầu tư, app crash vì RabbitMQ queue tắc.
• Team kiệt sức: DevOps làm việc 24/7 để restart pod, backend ngập trong log.

Phân tích: Tại sao sai?

• Tách quá vụn: 24 service cho team 12 người, mỗi dev phải maintain 2 service, vượt khả năng.
• Domain boundary mờ: Service nhỏ như “tính phí giao hàng” lẽ ra là logic trong Order Service.
• Thiếu DevOps maturity: Không có tracing (Jaeger), logging (ELK), CI/CD pipeline yếu.

Bài học: Modular Monolith trước

• Làm Modular Monolith: Tách boundary trong codebase (VD: /app/Order, /app/Payment), deploy chung.
• Tách microservice khi cần: Chỉ tách service độc lập, ít phụ thuộc (VD: Notification).
• Đầu tư monitoring: Dùng Jaeger, ELK để trace và log.

Code mẫu: Modular Monolith (Laravel)

// app/Order/Services/OrderService.php

namespace App\Order\Services;

class OrderService {

    public function createOrder($userId, $items) {

        return Order::create(['user_id' => $userId, 'items' => $items]);

    }

}

Microservice không phải “càng nhỏ càng xịn”. Team 12 người mà tách 24 service là “tự đào hố chôn mình”. Làm Modular Monolith trước, tách dần khi team lớn (>20 dev) và DevOps đủ mạnh. Đừng để demo cho sếp thành “phim kinh dị”!

Checklist tránh micro-suffering:

• Team <15 dev → Modular Monolith, focus MVP.
• Tách service ít phụ thuộc trước (VD: Notification).
• Setup tracing (Jaeger) và logging (ELK) trước khi tách.
• Định nghĩa domain boundary rõ ràng.

🎯 Tóm lại: 24 service cho 12 người là “mời gọi thảm họa”. Modular Monolith trước, tách microservice khi thực sự cần, để bug fix không thành “cuộc săn kho báu”!