“Tại sao lại cần tới 21 services? Như thế chẳng phải là overkill (giết gà dùng đao mổ trâu) sao?”
Đây là câu hỏi phổ biến nhất mà tôi nhận được khi thảo luận về kiến trúc microservice viết bằng Golang mà chúng tôi đã xây dựng để xử lý khối lượng scale khổng lồ. Câu trả lời ngắn gọn là: Không, bởi vì Định luật Conway là có thật.
Khi bạn có nhiều squad (đội nhóm) cùng chọc vào một codebase, sự chồng chéo tính năng sẽ tạo ra ma sát. Bằng cách áp dụng nghiêm ngặt Thiết kế Hướng Domain (Domain-Driven Design - DDD), chúng tôi đã cắt nhỏ cục monolith thương mại điện tử của mình thành 6 Domain Nghiệp vụ (Business Domains) có tính liên kết nội bộ cao (highly cohesive) nhưng lại lỏng lẻo với bên ngoài (loosely coupled). Mỗi domain hoàn toàn tự cung tự cấp và sở hữu cơ sở dữ liệu Postgres của riêng nó.
Dưới đây là bản bóc tách kỹ thuật của 6 domain cốt lõi và các service nằm bên trong chúng.
1. Luồng Thương mại (The Commerce Flow)
Đây là trái tim giao dịch của toàn bộ nền tảng. Nếu domain này sập, dòng tiền sẽ ngừng chảy.
- Checkout Service: Kẻ điều phối (The orchestrator). Nó quản lý các trạng thái biến động của giỏ hàng, xác thực lại giá từ catalog theo thời gian thực, và khởi tạo luồng Saga cho quá trình thanh toán.
- Order Service: Service này xử lý nghiêm ngặt vòng đời sau-khi-checkout. Nó quyết định 8 trạng thái của một đơn hàng (Pending, Confirmed, Paid, Cancelled, v.v.) và đóng vai trò là điểm phát (publisher) sự kiện trung tâm.
- Payment Service: Được bảo mật ở mức cao nhất. Tích hợp sâu với các API bên ngoài (Stripe, PayPal, VNPay, MoMo). Nó cũng chạy logic phát hiện GeoIP + VPN tự chế của chúng tôi để tự động chấm điểm gian lận (fraud scoring).
2. Sản phẩm & Nội dung (Product & Content)
Một domain thiên về đọc (read-heavy) được tinh chỉnh để có độ trễ cực thấp.
- Catalog Service: Nguồn chân lý duy nhất (Single source of truth) cho PIM (Quản lý Thông tin Sản phẩm). Nó xử lý các cấu trúc EAV (Entity-Attribute-Value) phức tạp, danh mục phân cấp sâu, và dữ liệu thương hiệu.
- Pricing Service: Bóc tách logic giá cả biến động ra khỏi Catalog. Nó quản lý việc quy đổi đa tiền tệ, tính thuế, và các tầng ghi đè giá (ví dụ: giá riêng theo từng Kho so với giá mặc định của SKU).
- Promotion Service: Chứa logic BOGO (Mua 1 tặng 1), tính toán giảm giá theo bậc (tiered discount), và sổ cái ghi nhận việc đổi mã coupon.
3. Vận chuyển & Kho bãi (Logistics)
Di chuyển các thực thể vật lý trong thế giới thực.
- Warehouse Service: Một hệ thống WMS (Quản lý kho) thu nhỏ. Nó xử lý việc phân mảnh tồn kho đa điểm, định vị vị trí kệ hàng (bin locators), và theo dõi các sự kiện giữ chỗ tồn kho (stock-reservation) có tính lũy đẳng (idempotent) để đảm bảo việc bán lố (overselling) là bất khả thi về mặt toán học.
- Fulfillment Service: Quyết định luồng thao tác vận hành nội bộ: Nhặt hàng (Picking), Đóng gói (Packing), và Bàn giao (Hand-off).
- Shipping Service: Một tác tử vùng biên (edge-agent) giao tiếp trực tiếp với các đơn vị vận chuyển vật lý (Grab, GHTK, v.v.) và chuẩn hóa các webhook cập nhật hành trình để các hệ thống nội bộ chỉ phải tiêu hóa một định dạng payload tiêu chuẩn duy nhất.
4. Hậu mãi (Post-Purchase)
Nơi việc giữ chân khách hàng diễn ra.
- Return Service: Một domain phức tạp đến đáng sợ. Nó phải điều phối việc nhập lại hàng với Warehouse, kích hoạt các lệnh gọi gRPC hoàn tiền (refund) về Payment service, và xử lý việc tạo mã RMA (Return Merchandise Authorization).
- Loyalty Service: Một database có thông lượng (throughput) cao, chuyên nuốt các sự kiện ‘đơn hàng hoàn tất’ để tăng hạng điểm và điều phối việc trả hoa hồng giới thiệu thông qua pattern Transactional Outbox.
5. Danh tính & Quyền truy cập (Identity & Access)
Những kẻ gác cổng.
- Auth Service: Cấp phát các chuỗi RS256 JWT không lưu trạng thái (stateless), xử lý các luồng OAuth2 (Google/Github), và quản lý logic MFA (Xác thực 2 yếu tố) hoàn toàn bằng Redis caching.
- User Service & Customer Service: Được chia tách rạch ròi để các công cụ phân quyền nội bộ RBAC dành cho nhân viên (User) không làm vấy bẩn dữ liệu profile khách hàng bên ngoài và các database phân tích giá trị vòng đời khách hàng (Customer).
6. Vận hành Nền tảng (Platform Operations)
Các tiện ích hạ tầng dùng chung mà các domain khác phụ thuộc rất nhiều vào.
- Gateway Service: Điểm đầu vào thực hiện việc định tuyến API, giới hạn tốc độ (rate-limiting) toàn cầu, và dập cầu dao điện (circuit breaking).
- Search Service: Một read-model theo pattern CQRS được xây dựng trên Elasticsearch. Nó tiêu thụ các sự kiện Dapr từ Catalog và Pricing service để tạo ra các document phẳng (flattened) đã được index, cho tốc độ truy vấn nhanh như chớp.
- Analytics & Notification: Các quan sát viên thụ động (Passive observers). Chúng ngồi ở cuối các hàng đợi Dapr, chờ đợi các sự kiện hệ thống báo về để cập nhật dashboard kinh doanh hoặc bắn tin nhắn/email chăm sóc khách hàng qua SendGrid/Twilio.
Giá trị của Sự chia tách
Nhìn vào hệ sinh thái qua lăng kính của 6 domain này, 21 services không còn giống như một mớ hỗn độn — chúng trông giống một dây chuyền nhà máy được tổ chức quy củ. Một con bug ở hệ thống Review không thể kéo sập hệ thống Payment. Một đợt bùng nổ traffic cục bộ trong mùa Flash Sale đồng nghĩa với việc chúng ta chỉ cần đẻ thêm 10 pods cho Order và Checkout services mà không phải đốt tiền để scale các service đang nằm im như Catalog hay Platform. Đây chính là giá trị thực tiễn cấp độ doanh nghiệp của Domain-Driven Design!
Bài viết này là một phần của series composable commerce. Để xem bản vẽ toàn hệ thống, kiến trúc luồng traffic, và lý luận đằng sau các quyết định thiết kế, hãy bắt đầu tại Bản vẽ Hệ thống Thương mại điện tử 21-Service: Kiến trúc & Luồng Dữ liệu.