🟡 Monolith
Một codebase, một deployment, mọi thứ trong 1 process. Đơn giản để bắt đầu và phát triển.
🔵 Microservices
Nhiều services nhỏ, độc lập, deploy riêng. Mỗi service có database riêng, giao tiếp qua API/message.
1. Monolith Architecture
Monolith:
┌─────────────────────────────────────┐
│ 1 Application │
│ ┌──────┐ ┌──────┐ ┌──────────┐ │
│ │ Auth │ │Orders│ │ Products │ │
│ └──────┘ └──────┘ └──────────┘ │
│ ┌──────┐ ┌──────┐ ┌──────────┐ │
│ │Payment│ │ Email│ │ Reports │ │
│ └──────┘ └──────┘ └──────────┘ │
│ 1 Database │
│ 1 Deployment │
└─────────────────────────────────────┘Ưu điểm:
- Đơn giản: Dễ phát triển, debug, test
- Performance: Gọi function trực tiếp, không qua network
- Transactions: ACID transactions dễ dàng
- Deploy: 1 artifact, 1 deploy
- Team nhỏ: Phù hợp 1-10 developers
Nhược điểm:
- Scale khó: Phải scale toàn bộ app dù chỉ 1 module cần
- Deploy risky: Thay đổi nhỏ → deploy lại toàn bộ
- Tech lock-in: Phải dùng 1 stack cho tất cả
- Codebase phình to: Khó hiểu, khó maintain khi lớn
2. Microservices Architecture
Microservices:
┌────────┐ ┌────────┐ ┌──────────┐
│ Auth │ │ Orders │ │ Products │
│Service │ │Service │ │ Service │
│ (Go) │ │(Node) │ │(Python) │
│ [DB1] │ │ [DB2] │ │ [DB3] │
└────┬───┘ └────┬───┘ └────┬─────┘
│ │ │
═════╪════════════╪═════════════╪══════
│ Message Bus / API Gateway
═════╪════════════╪═════════════╪══════
│ │ │
┌────┴───┐ ┌───┴────┐ ┌───┴──────┐
│Payment │ │ Email │ │ Reports │
│Service │ │Service │ │ Service │
│ (Java) │ │(Node) │ │(Python) │
│ [DB4] │ │ [DB5] │ │ [DB6] │
└────────┘ └────────┘ └──────────┘Ưu điểm:
- Scale độc lập: Orders service cần scale → chỉ scale nó
- Deploy độc lập: Thay đổi Auth → chỉ deploy Auth
- Tech freedom: Go cho performance, Python cho ML, Node cho real-time
- Fault isolation: Email service chết → không ảnh hưởng Orders
- Team ownership: Mỗi team sở hữu service riêng
Nhược điểm:
- Distributed complexity: Network calls, latency, failures
- Data consistency: Saga pattern thay vì ACID
- DevOps overhead: Docker, K8s, monitoring cho từng service
- Debugging khó: Distributed tracing cần thiết
3. Bảng So Sánh
| Tiêu chí | 🟡 Monolith | 🔵 Microservices |
|---|---|---|
| Complexity | Thấp ban đầu, cao khi lớn | Cao ban đầu, quản lý tốt khi lớn |
| Deploy | 1 unit, đơn giản | Nhiều units, CI/CD phức tạp |
| Scaling | Scale toàn bộ | Scale từng service |
| Tech Stack | 1 stack | Đa dạng (polyglot) |
| Team Size | 1-15 người | 15+ người, nhiều team |
| Data | 1 database, ACID | DB per service, eventual consistency |
| Testing | Unit + Integration dễ | Cần contract testing, E2E phức tạp |
4. Khi Nào Chọn?
Giữ Monolith khi:
• Startup/MVP giai đoạn đầu
• Team nhỏ (< 10 người)
• Domain chưa rõ ràng
• Không cần scale riêng từng module
Chuyển Microservices khi:
• Team lớn, cần ownership rõ ràng
• Modules cần scale khác nhau
• Cần deploy independent, release nhanh
• Domain đã ổn định, boundaries rõ ràng
⚠️ "Monolith First" — Martin Fowler:
Hầu hết startups nên bắt đầu bằng Monolith. Chỉ chuyển sang Microservices khi thực sự CẦN.
Premature decomposition là sai lầm phổ biến nhất.