Phần 0: Tại sao có thể tránh bẫy Magento $200K/Năm

Bất kỳ đội ngũ kỹ thuật nào xây dựng hệ thống nghiêm túc trên Magento cuối cùng cũng sẽ đụng phải ba bức tường giống nhau: bức tường bản quyền, bức tường khả năng chịu tải (scaling), và bức tường tốc độ phát triển (developer velocity). Câu hỏi chỉ là bạn sẽ đụng phải chúng trước hay sau khi chúng bào mòn tiền bạc và khách hàng thực sự của bạn.

Answer-first: Một Nền tảng Composable Commerce (Thương mại lắp ghép) được xây dựng trên 21 Go microservices, Kratos v2, và Dapr PubSub có thể thay thế Magento Enterprise — mang lại những năng lực thương mại y hệt (đa kho, saga thanh toán, hệ thống tích điểm, tìm kiếm thời gian thực) — với chi phí bản quyền bằng 0, cùng khả năng scale (mở rộng) từng service độc lập trong những khung giờ cao điểm.

Đây không phải là lý thuyết suông. Series này ghi lại các quyết định kiến trúc, cẩm nang chuyển đổi, và quá trình triển khai bằng Golang của chính xác nền tảng đó.

1. Ba Bức tường của Magento Enterprise

Bức tường 1: Chi phí Bản quyền

Magento Open Source thì miễn phí. Nhưng ngay khi doanh nghiệp của bạn cần đến những tính năng enterprise thực sự — danh mục B2B, quản lý tồn kho đa nguồn, hệ thống khuyến mãi nâng cao, hỗ trợ chuyên trách (dedicated support) — bạn sẽ phải nhìn sang Magento Commerce (nay là Adobe Commerce):

Với một công ty e-commerce Việt Nam xử lý 5,000–10,000 đơn hàng/ngày, bạn thường sẽ rơi vào khung $40K–125K — đó là chưa tính đến chi phí nhân sự kỹ sư để duy trì codebase PHP và hệ sinh thái module đặc thù của Magento.

Bức tường 2: Khả năng Chịu tải (Scaling)

Magento 2 là một hệ thống nguyên khối (monolith). Khi lưu lượng truy cập (traffic) tăng vọt vào ngày Black Friday hay 11.11, bạn không thể chỉ nâng cấp riêng luồng thanh toán (checkout). Bạn phải scale toàn bộ ứng dụng PHP, bao gồm cả việc duyệt danh mục sản phẩm, các trang CMS, bảng điều khiển admin, và tất tần tật mọi thứ khác — mặc dù chỉ có 3% hạ tầng của bạn là thực sự đang xử lý việc tạo đơn hàng.

Bài toán toán học trong vận hành cực kỳ tàn khốc:

Lượng traffic đỉnh điểm đòi hỏi gấp 10 lần năng lực Order + Payment
→ Khối monolith Magento phải scale mọi thứ gấp 10 lần
→ 10× Varnish, 10× PHP-FPM, 10× worker chạy cron của Magento
→ Hóa đơn AWS tăng vọt 10 lần chỉ cho 2 giờ flash sale

Nhưng với kiến trúc microservices:

Lượng traffic đỉnh điểm đòi hỏi gấp 10 lần năng lực Order + Payment
→ Chỉ scale riêng order-service (từ 3 pod → 30 pod)
→ Chỉ scale riêng payment-service (từ 2 pod → 20 pod)
→ Tất cả các service khác: không đổi
→ Hóa đơn AWS chỉ tăng thêm 15-20% cho 2 giờ flash sale

Đây không phải là lý thuyết. Đây chính xác là mô hình vận hành mà Shopee sử dụng trong ngày 11.11 và PayPay sử dụng trong các ngày chạy chiến dịch — cả hai đều được trình bày chi tiết trong series Kiến trúc Shopee và Kiến trúc PayPay trên trang này.

Bức tường 3: Tốc độ Phát triển (Developer Velocity)

Hệ thống module của Magento 2 — được xây dựng trên các pattern của Zend Framework 2 từ khoảng năm 2015 — tạo ra một loại nợ kỹ thuật (technical debt) cực kỳ đặc thù: mỗi tùy chỉnh (customization) đều là một plugin, preference, hoặc interceptor sẽ âm thầm hỏng hóc mỗi khi bạn nâng cấp lõi Magento.

Các triệu chứng thường rất dễ đoán:

• Một đợt nâng cấp phiên bản Magento ngốn mất 2–4 tuần chỉ để test hồi quy (regression testing)
• Kỹ sư mới vào cần 3–6 tháng mới có thể làm việc hiệu quả với lược đồ EAV, di.xml, events/observers, và layout XML
• Thêm một cổng thanh toán mới đòi hỏi phải đụng vào hơn 7 file trải dài qua 3 module khác nhau
• Chạy unit test chậm rì vì toàn bộ quy trình bootstrap của Magento phải được load lại cho mỗi test

2. Kiến trúc Composable Commerce

Nền tảng được ghi chép trong series này xử lý toàn bộ hành trình của khách hàng mà không cần đến Magento:

graph TD
    subgraph "Clients"
        FE["Customer Website (Next.js)"]
        ADMIN["Admin Dashboard (React)"]
    end

    subgraph "API Gateway"
        GW["Gateway — Auth · Rate Limit · Routing"]
    end

    subgraph "Identity"
        AUTH["Auth (JWT RS256 + OAuth2 + MFA)"]
        CUST["Customer"]
    end

    subgraph "Product"
        CAT["Catalog"]
        PRC["Pricing (dynamic rules, tax)"]
        PROMO["Promotion (BOGO, coupons, tiers)"]
        SEARCH["Search (Elasticsearch)"]
    end

    subgraph "Commerce"
        CK["Checkout (saga orchestrator)"]
        ORD["Order (8-state lifecycle)"]
        PAY["Payment (Stripe, VNPay, MoMo)"]
    end

    subgraph "Logistics"
        WH["Warehouse (multi-warehouse WMS)"]
        FF["Fulfillment"]
        SH["Shipping (GHN, Grab)"]
    end

    FE & ADMIN --> GW
    GW --> AUTH & CUST & CAT & SEARCH & CK & ORD
    CK -->|"CreateOrder"| ORD
    CK -->|"Authorize"| PAY
    ORD -->|"order.confirmed (Dapr event)"| WH
    ORD -->|"order.paid (Dapr event)"| FF
    FF -->|"fulfillment.completed"| SH

Tech stack (ADR-002, ADR-005):

• Ngôn ngữ: Go 1.25
• Microservice framework: Kratos v2 (framework cấp độ production của Google, được dùng bởi Bilibili)
• API Nội bộ: gRPC (Protocol Buffers)
• API Đối ngoại: REST qua gRPC-Gateway
• Giao tiếp bất đồng bộ (Async): Dapr PubSub (Dùng Redis Streams ở local dev, và Kafka-compatible ở production)
• Cơ sở dữ liệu: PostgreSQL 15+ cho mỗi service (mô hình database-per-service, ADR-004)
• Monorepo: Microsoft Rush (21 Go services + Next.js + React Admin)
• Deploy: Kubernetes (k3d cho local) + ArgoCD GitOps (ADR-009)

3. Lộ trình Chuyển đổi: Strangler Fig 3 Giai đoạn

Rào cản chí mạng đối với bất kỳ cuộc dịch chuyển production nào: bạn không thể tắt Magento để bảo trì trong lúc đang đập đi xây lại. Cửa hàng vẫn phải tiếp tục xử lý đơn hàng trong suốt toàn bộ quá trình chuyển đổi, một quá trình kéo dài 14–19 tuần từ đầu đến cuối.

graph LR
    subgraph "Giai đoạn 1: Read-Only (Tuần 1–3)"
        direction TB
        P1C["Client"] --> P1G["Gateway"]
        P1G -->|"Read"| P1M["Microservices"]
        P1G -->|"Write"| P1Mg["Magento"]
        P1Mg -->|"CDC Sync"| P1M
    end

    subgraph "Giai đoạn 2: Dual-Write (Tuần 4–9)"
        direction TB
        P2C["Client"] --> P2G["Gateway"]
        P2G --> P2M["Microservices"]
        P2M -->|"Dapr Events"| P2Bus["Event Bus"]
        P2Bus -->|"Sync"| P2Mg["Magento"]
    end

    subgraph "Giai đoạn 3: Full Cutover (Tuần 10–19)"
        direction TB
        P3C["Client"] --> P3G["Gateway"]
        P3G --> P3M["Microservices"]
        P3M -.->|"Archive (Cửa sổ 30 ngày)"| P3Mg["Magento Hot Standby"]
    end

Giai đoạn 1 — Chuyển đổi Read-Only (Chỉ đọc): Triển khai các Go microservice ở chế độ read-only. API Gateway điều hướng các request GET sang microservices, còn POST/PUT/DELETE vẫn đi vào Magento. Một service đồng bộ CDC (Debezium đọc binlog của MySQL) sẽ giữ cho data của microservices luôn được cập nhật. Rủi ro: bằng 0. Rollback: tắt feature flag là xong.

Giai đoạn 2 — Dual-Write (Ghi song song): Kích hoạt các API ghi (write APIs) trên microservices, làm từng domain một (Customer → Catalog → Order). Dapr PubSub lan truyền các thay đổi theo cả hai chiều với cơ chế giải quyết xung đột timestamp-wins (cái nào mới hơn thì thắng). Feature flag cho phép rollback về lại Magento trong vòng chưa tới 10 giây đối với bất kỳ service nào.

Giai đoạn 3 — Full Cutover (Chuyển đổi Toàn phần): Dịch chuyển traffic từ từ theo các mức 25% → 50% → 75% → 100% cho mỗi service. Magento vẫn được giữ ở chế độ hot standby trong vòng 30 ngày như một tấm lưới an toàn để phòng hờ rollback. ArgoCD GitOps đảm nhiệm quá trình triển khai tịnh tiến (progressive delivery) này.

4. Series này Bao hàm những Gì

Cuộc chuyển đổi 3 giai đoạn này chỉ khả thi nếu bạn giải quyết được hàng loạt các bài toán kỹ thuật hóc búa trước đã. Series này sẽ dẫn bạn đi qua từng vấn đề một:

Dành cho Ai?

Series này được viết nhắm đến ba đối tượng độc giả cùng một lúc:

• PM / BA / CTO: Phần 0, 1, 10 cung cấp cho bạn bài toán kinh doanh, tiến độ chuyển đổi, và các sự đánh đổi về kiến trúc mà không đòi hỏi chuyên môn sâu về Go.
• Kỹ sư Backend: Phần 3–9 đi kèm các đoạn code Go có thể chạy được, ứng dụng Kratos v2, Dapr SDK, và gRPC-Gateway.
• Kiến trúc sư / Tech Leads: Phần 1, 4, 9, 10 bao quát việc phân rã DDD, thiết kế giao thức, các mô hình saga, và luận điểm của các ADR vốn sẽ định hình nền tảng của bạn trong 5 năm tới.

Hãy bắt đầu ngay với phần phân rã domain: Phần 1 — Bounded Contexts trong DDD: Phân rã các Module Magento.

Câu Hỏi Thường Gặp (FAQ)

Toàn bộ quá trình chuyển đổi mất bao lâu?

Tính từ đầu đến cuối (End-to-end): 14–19 tuần cho một hệ thống Magento 2 đang chạy production. Giai đoạn 1 (read-only) mất 2–3 tuần. Giai đoạn 2 (dual-write, làm từng domain một) mất 4–6 tuần. Giai đoạn 3 (full cutover, điều hướng traffic từng service một) mất 8–10 tuần. Khung cửa sổ an toàn để rollback luôn được giữ mở trong suốt quá trình này.

Tôi có cần phải viết lại luôn cả frontend của Magento không?

Không. Chiến lược chuyển đổi này nhắm tới tầng API backend trước. Frontend Magento Luma/PWA Studio của bạn vẫn có thể tiếp tục trỏ tới API Gateway, và Gateway sẽ proxy xuống đúng backend (Magento hay microservices) tùy thuộc vào trạng thái của feature flag. Việc chuyển đổi frontend là một luồng công việc (workstream) hoàn toàn tách biệt.

Quy mô đội ngũ tối thiểu cho cuộc chuyển đổi này là bao nhiêu?

Chúng tôi khuyến nghị: 2–3 kỹ sư Go backend, 1 kỹ sư DevOps/SRE (để lo CDC, Kubernetes, ArgoCD), 1 DBA hoặc data engineer (để lo việc trích xuất EAV và ánh xạ danh tính), và 1 kỹ sư QA. Quá trình chuyển đổi có thể được thực thi bởi một đội gồm 4–5 người nếu các kỹ sư có năng lực làm việc đa nhiệm (cross-functional).

Kratos v2 đã sẵn sàng cho production chưa?

Rồi. Kratos v2 (go-kratos.dev) được maintain bởi đội ngũ kỹ sư của Bilibili và được sử dụng trên môi trường production bởi rất nhiều hệ thống Go quy mô lớn tại Trung Quốc và Đông Nam Á. Nó cung cấp một lớp trừu tượng (abstraction) gọn gàng nằm phía trên gRPC + HTTP transport, tính năng tiêm phụ thuộc (dependency injection) dựa trên Wire, và chuỗi middleware có thể cắm-rút linh hoạt — khiến nó trở thành mảnh ghép hoàn hảo cho một nền tảng 21-service, nơi sự nhất quán về các design pattern quan trọng hơn sự tự do bay bổng của framework.

Bài viết này nằm trong Series Chuyển đổi sang Composable Commerce. Hãy xem toàn bộ mục lục để nắm bắt ngữ cảnh kiến trúc đầy đủ nhất.

Bạn cần hỗ trợ đánh giá rủi ro cho đợt chuyển đổi nền tảng sắp tới? → Đặt lịch Tư vấn Kiến trúc 1:1