Kiến trúc Ecommerce 2026: Vượt Qua Nợ Kỹ Thuật Khi Chuyển Đổi Sang Composable Commerce
Trên lý thuyết, MACH (Microservices, API-first, Cloud-native, Headless) và Composable Commerce là “chén thánh” của ngành thương mại điện tử. Tuy nhiên, khi hệ thống đạt mốc xử lý hàng triệu giao dịch, những vấn đề về tính nhất quán dữ liệu và chi phí quan sát hệ thống (Observability) mới thực sự lộ diện. Bài viết này đúc kết kinh nghiệm xương máu từ đội ngũ kiến trúc sư trưởng (Chief Architect) khi đưa hệ thống từ Monolith lên Composable.
Điểm nghẽn thực sự khi chia nhỏ hệ thống (Eventual Consistency)
Answer-first: Điểm nghẽn lớn nhất không nằm ở việc thiết lập Kafka hay API Gateway, mà ở bài toán “Eventual Consistency” (Tính nhất quán cuối cùng). Để ngăn chặn tình trạng khách mua lố hàng (oversell) do độ trễ cập nhật tồn kho từ Event-bus, hệ thống bắt buộc phải áp dụng cơ chế Optimistic Locking ngay tại tầng BFF.
Khi tách biệt Search Engine (như Algolia) và Inventory Service thông qua Event-bus, dữ liệu cần vài giây để đồng bộ.
- Nếu khách hàng “Add to Cart” sản phẩm cuối cùng, Inventory Service trừ stock ngay lập tức.
- Tuy nhiên, Search UI chưa kịp nhận event để ẩn sản phẩm. Khách hàng thứ 2 vẫn thấy hàng và bấm mua, dẫn đến lỗi.
- Giải pháp thực chiến: Sử dụng Redis tại tầng BFF (Backend-For-Frontend) để khóa tạm thời (Lock) trạng thái giỏ hàng trước khi event hoàn tất vòng đời. Đừng bao giờ phó mặc hoàn toàn cho Event-bus trong giao dịch thanh toán.
Chi phí ẩn và thời gian “Stabilize” của Composable
Answer-first: Cần trung bình 3-4 tháng để thay thế và ổn định một module lõi như Checkout. Chi phí ẩn đắt đỏ nhất chính là việc xây dựng hệ thống Khả năng quan sát (Observability), vốn tiêu tốn thêm 20-30% nguồn lực dự án để thiết lập Distributed Tracing.
Trong kiến trúc Monolith, trace một lỗi thanh toán chỉ cần đọc một file log. Với Composable, một request thanh toán đi qua:
- Storefront
- BFF (Backend-For-Frontend)
- Cart Service
- Payment Gateway
- Order Service
Thiếu OpenTelemetry ngay từ dòng code đầu tiên, đội vận hành (SRE) sẽ hoàn toàn “mù” khi sự cố xảy ra. Tracing không phải là tính năng bổ sung (nice-to-have), nó là tiêu chuẩn bắt buộc (Definition of Done) của Composable Commerce.
Giải bài toán đồng bộ Monolith cũ: Kiến trúc CDC
Answer-first: Tránh tuyệt đối việc ghi song song (Dual-write) từ logic ứng dụng vì rủi ro partial failure. Giải pháp tối ưu là áp dụng Change Data Capture (CDC) với Debezium, đọc trực tiếp từ binlog của hệ thống cũ và stream qua Kafka để đồng bộ về hệ thống mới.
Nhiều team mắc sai lầm khi bắt Application Code gọi API ghi vào cả database cũ và mới. Nếu lời gọi API thứ 2 bị timeout, dữ liệu sẽ bất đồng bộ vĩnh viễn.
Dưới đây là sơ đồ luồng dữ liệu chuẩn cho giai đoạn Strangler Fig (chạy song song cũ - mới):
graph TD
subgraph Monolith Legacy
APP[Monolith App] -->|Ghi dữ liệu| DB[(Legacy DB MySQL/PG)]
end
subgraph CDC & Event Streaming
DB -.->|Đọc Binlog| DEB[Debezium CDC]
DEB -->|Publish Event| KAFKA[Kafka Event Bus]
end
subgraph Composable Services
KAFKA -->|Consume| OS[Order Service]
KAFKA -->|Consume| INV[Inventory Service]
OS --> O_DB[(Order DB Mới)]
INV --> I_DB[(Inventory DB Mới)]
end
Nhờ CDC, hệ thống mới chỉ đóng vai trò Consumer thụ động. Tiến trình giao dịch chính của người dùng trên hệ thống cũ hoàn toàn không bị suy giảm hiệu năng hay chịu rủi ro timeout từ mạng.
FAQ: Chuyển đổi Composable Commerce
Khi nào doanh nghiệp mới nên chuyển sang Composable Commerce?
Khi doanh thu đạt mốc 5 triệu USD/năm hoặc khi nền tảng nguyên khối (Monolith) hiện tại bắt đầu cản trở tốc độ ra mắt tính năng mới. Đối với các startup nhỏ, việc dùng SaaS đóng gói vẫn tối ưu về chi phí hơn.
Tại sao lại cần BFF (Backend-For-Frontend)?
BFF giúp tổng hợp dữ liệu từ nhiều microservices khác nhau thành một API duy nhất trả về cho Frontend, giảm thiểu số lượng network calls và đóng vai trò như một lớp đệm bảo vệ (Circuit Breaker) khi các service phía sau bị nghẽn.