Microservices & Micro Frontend — Kiến trúc cho hệ thống lớn trong 2026
Tại sao Monolith không còn đủ?
Hãy tưởng tượng một team 50 người cùng làm việc trên một codebase duy nhất. Mỗi lần deploy phải build lại toàn bộ. Một bug nhỏ ở module thanh toán có thể kéo sập cả trang landing. Một team frontend muốn dùng React 19, team kia vẫn mắc kẹt ở React 16 vì không ai dám upgrade.
Đó là thực tế của kiến trúc Monolith khi hệ thống đạt đến một quy mô nhất định.
Microservices và Micro Frontend ra đời để giải quyết chính xác vấn đề này — nhưng chúng cũng đi kèm sự phức tạp riêng mà nếu không hiểu rõ, bạn sẽ dễ dàng biến một hệ thống đơn giản thành một mớ hỗn độn phân tán.
Microservices là gì? (Và không phải là gì?)
Microservices không phải là "chia nhỏ code thành nhiều service". Đó là cái bẫy phổ biến nhất.
Microservices là cách tổ chức hệ thống theo business capability — mỗi service có trách nhiệm rõ ràng, có database riêng, có team riêng sở hữu, và có thể deploy độc lập.
❌ Sai: Chia theo layer kỹ thuật
- service-database
- service-api
- service-frontend
✅ Đúng: Chia theo business domain (DDD)
- order-service
- payment-service
- inventory-service
- notification-service
Nguyên tắc cốt lõi: "High cohesion, loose coupling". Mỗi service phải có thể thay đổi mà không ảnh hưởng đến service khác.
Domain-Driven Design — Chìa khóa để phân tách đúng
Câu hỏi khó nhất trong Microservices không phải là kỹ thuật — mà là "Chia service ở đâu?"
Domain-Driven Design (DDD) cung cấp công cụ để trả lời câu hỏi này:
- Bounded Context: ranh giới ngôn ngữ nghiệp vụ — cùng từ "User" nhưng trong
auth-servicelà thông tin đăng nhập, trongprofile-servicelà thông tin cá nhân, trongorder-servicechỉ cầnuserId. - Aggregate: nhóm các domain object thay đổi cùng nhau, đây là đơn vị nhỏ nhất khi thiết kế service boundary.
- Domain Events: khi
order-servicetạo đơn hàng thành công, nó phát raOrderCreatedevent —payment-servicevàinventory-servicelắng nghe và xử lý độc lập.
Inter-service Communication — Sync hay Async?
Đây là quyết định thiết kế quan trọng nhất:
Synchronous (REST / gRPC)
Client → API Gateway → Order Service → Payment Service (gRPC) → Response
Dùng khi: cần response ngay lập tức, như kiểm tra tồn kho trước khi cho phép đặt hàng.
Vấn đề: nếu Payment Service chết → Order Service phải chờ timeout → toàn bộ request bị block.
Asynchronous (Event-Driven)
Order Service → Kafka → Payment Service
→ Inventory Service
→ Notification Service
Dùng khi: không cần response ngay, như gửi email xác nhận đơn hàng.
Lợi ích: fault isolation — payment service chết thì message vẫn còn trong queue, khi service sống lại sẽ xử lý tiếp.
Data Architecture: Mỗi Service một Database
Database per Service là pattern bắt buộc trong Microservices — không chia sẻ database giữa các service.
Nhưng điều này tạo ra vấn đề mới: Distributed Transactions.
Ví dụ: Đặt hàng requires trừ tồn kho + tạo payment + gửi notification. Nếu payment thành công nhưng trừ tồn kho thất bại?
Saga Pattern giải quyết vấn đề này theo hai cách:
Choreography Saga (Event-driven):
OrderCreated → PaymentService (PaymentProcessed) → InventoryService (StockReserved) → ...
Nếu thất bại: StockReservationFailed → PaymentService rollback → OrderService rollback
Orchestration Saga (Central coordinator):
Saga Orchestrator điều phối toàn bộ luồng, gọi từng step và xử lý compensation
Micro Frontend — Microservices cho UI
Khi Backend đã chia Microservices, Frontend vẫn là một Monolith thì bạn vẫn bị bottleneck ở frontend.
Micro Frontend áp dụng triết lý tương tự cho UI: mỗi team sở hữu một phần của UI, deploy độc lập, tích hợp vào Shell App.
Shell Application (Host)
├── Header MFE (Team Platform)
├── Product Catalog MFE (Team Catalog)
├── Shopping Cart MFE (Team Commerce)
└── Checkout MFE (Team Payments)
Webpack Module Federation — Công nghệ nền tảng
Với Webpack 5 Module Federation, các MFE có thể share code ở runtime:
// product-mfe/webpack.config.js
new ModuleFederationPlugin({
name: 'productMfe',
filename: 'remoteEntry.js',
exposes: {
'./ProductCard': './src/components/ProductCard',
},
shared: ['react', 'react-dom'], // share với shell, tránh duplicate
})
// shell/webpack.config.js
new ModuleFederationPlugin({
remotes: {
productMfe: 'productMfe@https://product.example.com/remoteEntry.js',
},
})
Kết quả: Team Catalog deploy MFE riêng lên CDN của họ, Shell App load dynamically tại runtime — không cần rebuild shell khi catalog thay đổi.
BFF Pattern — Cầu nối giữa Micro Frontend và Microservices
Không nên để Micro Frontend gọi thẳng vào từng Microservice — đó là recipe cho spaghetti code và performance issues.
Backend for Frontend (BFF) là một layer trung gian, được thiết kế riêng cho từng loại client:
Mobile App → Mobile BFF → [User Service, Order Service, ...]
Web Frontend → Web BFF → [User Service, Order Service, ...]
Partner API → Partner BFF → [Product Service, Inventory Service, ...]
Mỗi BFF aggregate dữ liệu từ nhiều services, transform về format phù hợp cho client của nó, tránh over-fetching hay under-fetching.
API Gateway — Traffic cop của hệ thống
API Gateway xử lý những concern chung cho toàn bộ Microservices:
- Authentication & Authorization: verify JWT một lần, không cần từng service tự làm
- Rate Limiting: bảo vệ backend khỏi DDoS
- Load Balancing & Service Discovery: route request đến đúng instance
- Circuit Breaker: tự động ngắt kết nối khi service downstream có vấn đề
Các lựa chọn phổ biến 2026: Kong, APISIX, Envoy (cho Kubernetes native).
Testing Strategy — Kiểm thử hệ thống phân tán
Testing Microservices cần chiến lược riêng. Testing Pyramid trong distributed system:
[E2E Tests] ← ít, chậm, đắt
[Integration Tests]
[Contract Tests] ← quan trọng với Microservices!
[Unit Tests] ← nhiều, nhanh, rẻ
Contract Testing với Pact đặc biệt quan trọng: thay vì mock service khác một cách tùy tiện, Pact đảm bảo contract giữa consumer và provider luôn được verified.
Payment Service (consumer) định nghĩa:
"Tôi expect Order Service trả về { orderId, amount, status }"
Order Service (provider) xác nhận:
"Tôi cam kết trả về đúng format đó"
→ Nếu Order Service thay đổi response schema → CI pipeline của Payment Service thất bại
Observability — Bạn không thể fix những gì bạn không thấy
Distributed tracing là bắt buộc. Khi một request đi qua 5 services, bạn cần biết bottleneck ở đâu.
OpenTelemetry là standard 2026 cho observability:
Request ID: abc-123
→ API Gateway (2ms)
→ Order Service (15ms)
→ Inventory Service (8ms) ← đây là bottleneck!
→ Payment Service (45ms)
→ Notification Service (3ms async)
Total: 73ms
Stack phổ biến: OpenTelemetry (instrumentation) + Jaeger/Tempo (tracing) + Prometheus (metrics) + Grafana (visualization).
Khi nào NÊN và KHÔNG NÊN dùng Microservices?
Nên dùng khi:
- Team > 20 người, nhiều team làm song song
- Cần scale từng phần độc lập (payment service cần scale x10 vào Black Friday)
- Domain phức tạp, nhiều bounded context rõ ràng
- Yêu cầu availability cao, không thể để một bug hạ cả hệ thống
Chưa nên dùng khi:
- Startup giai đoạn đầu, team < 10 người
- Domain chưa ổn định, business logic thay đổi liên tục
- Không có DevOps/Platform team để quản lý infrastructure
"Monolith first, Microservices when needed" — Martin Fowler
Nếu bạn muốn đi sâu hơn vào từng chủ đề, mình đã tổng hợp thành một series 30 bài đi từ nền tảng đến production:
→ Thiết kế hệ thống Microservices & Micro Frontend — Từ cơ bản đến Production
Series bao gồm:
- Phần 1–3: Nền tảng DDD, kiến trúc tổng quan full-stack
- Phần 4–5: Thiết kế Microservices Backend — API Design, Service Communication, Data Architecture
- Phần 6–7: Micro Frontend từ nguyên lý đến xây dựng thực tế (Module Federation, Shell App, SSO)
- Phần 8–9: API Gateway, BFF Pattern, GraphQL Federation
- Phần 10–11: Testing + CI/CD Pipeline cho distributed system
- Phần 12: Full-stack Observability + Production Readiness Checklist
- Phần 13: Case study E-Commerce Platform thực tế + Migration Guide từ Monolith
Nếu bài này hữu ích, hãy upvote và chia sẻ cho những ai đang tìm hiểu về Microservices nhé!
All rights reserved
