Microservices không phải thần dược — 80% startup nên dùng Monolith

Microservices là gì

Microservices là kiến trúc tách ứng dụng thành nhiều service nhỏ. Mỗi service chạy độc lập, quản lý dữ liệu riêng, giao tiếp qua API hoặc message queue. Nghe có vẻ lý tưởng, nhưng chi phí vận hành cực cao.

Monolith là gì

Monolith là kiến trúc gói toàn bộ logic backend vào một ứng dụng duy nhất. Một codebase, một deploy pipeline, một database. Đơn giản, dễ hiểu và dễ triển khai.

Microservices — tại sao mọi người bị hấp dẫn

• Nghe giống “kiến trúc của Big Tech”.
• Team phát triển độc lập từng module.
• Scale từng service theo nhu cầu.

Hấp dẫn trên slide thuyết trình. Nhưng thực tế thì chơi microservices là chơi với độ phức tạp.

Chi phí ẩn của Microservices

Triển khai microservices = bạn phải giải bài toán DevOps trước cả bài toán sản phẩm.

• Service Discovery
• API Gateway
• Load balancer
• Monitoring, tracing, logging
• Message queue hoặc event bus
• CI/CD cho nhiều service

Nếu bạn chưa giải thích được observability, circuit breaker, distributed tracing, retry logic, thì microservices sẽ trở thành mớ hỗn độn cực nhanh.

Startup không cần Microservices vì… chưa có gì để scale

Ở giai đoạn đầu:

• Người dùng ít
• Chưa biết nhu cầu thực sự
• Tính năng còn thay đổi liên tục
• Các luồng nghiệp vụ chưa ổn định

Microservices chỉ phù hợp khi bạn muốn tối ưu hiệu suất, còn khi bạn cần tốc độ triển khai, monolith thắng.

Monolith nhanh hơn trong 4 khía cạnh quan trọng

1. Tốc độ phát triển

cd backend/
git pull
docker compose up -d

Không phải chạy 17 dịch vụ chỉ để debug một endpoint.

2. Dễ debug

Monolith: log ở một nơi.
Microservices: log ở 10 nơi, cần distributed tracing để lần lỗi.

3. Deploy đơn giản

Monolith: deploy một app.
Microservices: deploy nhiều service + dependency + version.

4. Chi phí thấp

Monolith: 1 server là đủ.
Microservices: tốn tiền cho cluster, container registry, monitoring, message queue.

Microservices chỉ phù hợp khi

• Hệ thống traffic lớn và đã có user thật
• Team dev nhiều, chia domain rõ ràng
• Có DevOps/SRE quản lý hạ tầng
• Quy trình CI/CD và monitoring hoàn chỉnh

Monolith phù hợp khi

• Startup early stage
• Traffic chưa lớn
• Thay đổi tính năng liên tục
• Team dev ít người (1–5 dev)

Chiến lược “Monolith đầu tiên, Microservices sau”

Không ai cấm bạn chuyển sang microservices sau này. Cách làm thông minh:

1. Bắt đầu bằng monolith
2. Tách module khi có bottleneck
3. Chỉ tách service khi có lý do (ví dụ: scale độc lập hoặc domain rõ ràng)

Bài học từ các Big Tech

• Amazon bắt đầu với monolith, sau đó mới tách services
• Uber đã phải rollback microservices vì quá phức tạp
• Basecamp khuyến cáo startup tuyệt đối tránh microservices sớm

Kết luận

Microservices không phải thần dược. Nó giải quyết bài toán scale, nhưng cái giá phải trả là độ phức tạp. Với 80% startup, mục tiêu quan trọng nhất là ra sản phẩm, có user, kiếm tiền. Monolith giúp bạn làm điều đó nhanh hơn, rẻ hơn và dễ debug hơn.

Bắt đầu bằng monolith. Scale bằng giá trị. Chỉ dùng microservices khi bạn thật sự cần.