Blog
Architecture

Microservices vs Monolith: Lựa chọn kiến trúc phù hợp cho startup

N
Nguyễn Văn An· CTO
·28/02/2025·12 phút đọc

Năm 2024, một startup fintech tìm đến chúng tôi với vấn đề: họ đang phát triển MVP nhưng kiến trúc microservices họ thiết kế có 12 service, Kubernetes cluster, service mesh và distributed tracing — tổng thời gian setup môi trường dev là 4 tiếng. Team 4 kỹ sư dành 60% thời gian cho infrastructure thay vì business logic. Đây là câu chuyện điển hình của premature optimization và là lý do chúng tôi muốn nói thẳng về chủ đề này.

Monolith không phải là từ xấu. Amazon, Netflix, Shopify — tất cả đều bắt đầu với monolith và chỉ chuyển sang microservices khi thực sự cần thiết. "Modular monolith" — monolith được tổ chức theo bounded context rõ ràng — là kiến trúc hoàn toàn phù hợp cho giai đoạn 0-1 của product. Nó giúp team di chuyển nhanh, dễ debug và dễ thay đổi requirement (điều cực kỳ quan trọng với startup). Chúng tôi khuyến nghị: nếu team dưới 15 người và product chưa có Product-Market Fit, hãy dùng modular monolith.

Microservices phát huy giá trị khi: (1) Các phần khác nhau của hệ thống có yêu cầu scale hoàn toàn khác nhau — ví dụ module search cần scale horizontal trong khi module billing chỉ cần vertical; (2) Team đủ lớn để ownership service riêng biệt — mỗi service cần ít nhất 2-3 kỹ sư; (3) Các phần của hệ thống có deployment cycle khác nhau; (4) Hệ thống đã đủ ổn định về domain model để xác định đúng bounded context. Sai lầm lớn nhất là xác định service boundaries quá sớm khi domain chưa ổn định — dẫn đến "distributed monolith" tệ hơn cả hai lựa chọn.

Lộ trình chúng tôi thường khuyến nghị: bắt đầu với well-structured monolith sử dụng clean architecture (hoặc hexagonal architecture), tách biệt rõ domain logic khỏi infrastructure. Khi một phần nào đó cần scale riêng hoặc team đủ lớn, extract ra thành service độc lập — nhưng hãy extract từng service một, không phải refactor toàn bộ cùng lúc. Dùng Strangler Fig Pattern: service mới và cũ chạy song song, dần dần chuyển traffic sang service mới. Đừng để áp lực "industry best practice" khiến bạn làm điều phản tác dụng với context cụ thể của mình.

Tags:

#Microservices#Architecture#Backend#System Design
N

Tác giả

Nguyễn Văn An

CTO · ANT Solutions & Services

Kỹ sư công nghệ với hơn 8 năm kinh nghiệm xây dựng hệ thống AI và phần mềm doanh nghiệp. Chia sẻ kiến thức kỹ thuật và bài học thực tế từ các dự án production.

Có câu hỏi về chủ đề này?

Đội ngũ kỹ sư ANT Solutions sẵn sàng thảo luận và tư vấn cho dự án cụ thể của bạn.