グローバル展開にむけた基盤の再構築 (Rebuilding Foundation for Global Expansion)

Mercari · 2025 · 4. Điều chỉnh · Độ khó: Trung bình — bài gốc

Bài mở đầu series "Mercari Global App" (ngoài sheet; sheet chỉ có trang mục lục). Tác giả là người dẫn dắt cuộc chuyển sang microservices và đội Platform Engineering của Mercari, nên phần tự đánh giá là "theo tác giả". Các bài cùng series: Mercari 2025 · Mercari 2025 · Mercari 2025 · Mercari 2025.

Bối cảnh

• Mua hộ xuyên biên giới từ 2019 qua đối tác (khách nước ngoài đặt trên site đối tác, đối tác mua trên Mercari); GMV tăng 15 lần trong 3 năm. Năm 2024 mở cho khách Đài Loan, Hồng Kông tạo tài khoản trực tiếp trên web Mercari Nhật. Nhưng hệ Nhật giả định một tiền tệ, một ngôn ngữ; tính năng xuyên biên giới được đắp lên trên.
• Các lần ra nước ngoài trước: Mỹ và Anh bắt đầu bằng cùng codebase deploy riêng từng nước (dữ liệu tách), rồi code đầy if theo nước và quyết định chậm vì phải thống nhất giữa các nước; cuối cùng fork thành hệ độc lập. Fork làm được vì lúc đó còn là monolith. Hệ quả: mỗi nước mới là một hệ mới, tính năng trùng lặp, mỗi nền tảng một đội riêng.
• Lịch sử backend: monolith → từ khoảng 2017, tổ chức lớn nhanh, lỗi một phần làm sập cả dịch vụ, hệ on-prem thành nút thắt, nên chuyển sang microservices + cloud theo strangler pattern (gateway đứng trước, cắt từng chức năng ra service, chuyển dần traffic). Hơn 100 service đã lên cloud. Song song là các nền tảng dùng chung (ID, thanh toán Merpay, marketing).

Thay đổi chính

• Tự đánh giá năm 2025:
  • Phần lõi C2C (quản lý giao dịch, vận chuyển) vẫn nằm trong monolith và DB của nó: strangler chỉ cắt được phần "proxy" phía trên, nhiều chỗ không đi tới bước chuyển dữ liệu, vì logic gắn quá chặt. Theo tác giả, không xử lý phần lõi này từ đầu là "bài học lớn".
  • C2C và B2C (Shops) có giao dịch, vận chuyển, quản lý sản phẩm riêng, nên trải nghiệm không thống nhất.
  • Microservices: thống nhất tối thiểu (Go, Spanner/CloudSQL, Kubernetes) nhưng polyrepo (1 service = 1 repo) và mỗi team tự quyết cấu trúc, nên nhiều service nhỏ, mỗi cái làm hơi khác nhau; chia quá nhỏ, ranh giới domain sai; đổi tổ chức thường xuyên kéo theo chuyển giao ownership tốn kém; thêm tính năng phải sửa nhiều service của nhiều team.
  • Shops dùng monorepo cho mọi microservice (trải nghiệm như monolith, deploy tách), nhưng hạ tầng riêng cho monorepo đó đắt; môi trường test nhân bản mọi service cho mỗi PR, mỗi service một DB.
• Chiến lược mới: một nền tảng toàn cầu cho mọi nước, "lai giữa mở rộng và xây lại":
  • Mở rộng các nền tảng dùng chung đã thiết kế để mở rộng và đủ lớn, độc lập (cỡ "thay được bằng một SaaS"): ID dùng chung toàn cầu, thanh toán qua Merpay nối Stripe, search, marketing. Không phụ thuộc vào các microservice nhỏ, không phụ thuộc monolith.
  • Xây lại giao dịch, vận chuyển, quản lý sản phẩm/mặt hàng, với giả định nhiều nước, nhiều tiền tệ, thuế và luật khác nhau, C và B như nhau; mục tiêu cuối là thay cả nền của Nhật.
  • Modular monolith có thể deploy tách từng module khi cần (gần ý Service Weaver); giai đoạn đầu không gán module cho team cố định.
  • Stack: GKE của đội Platform, AlloyDB thay Spanner để tránh khoá vào Google Cloud và dùng hệ sinh thái PostgreSQL (CockroachDB vẫn được cân nhắc); app iOS/Android/Web mở rộng repo của Nhật thành monorepo.
• Tenets chung cho đội Nhật và Ấn Độ, ví dụ "Design for two": luôn thiết kế cho ít nhất hai nước, vì từ 2 lên 3 dễ hơn nhiều so với từ 1 lên 2.

Vì sao

• Fork từng nước không còn khả thi khi đã có hàng trăm microservice; xây lại toàn bộ quá đắt; mở rộng hệ hiện có thì kéo theo giả định của thị trường Nhật.
• Theo tác giả, gốc của chi phí vận hành microservices là để mỗi service quá tự do; lần sau nên chọn module lớn hơn trong một codebase.

Bài học cho SWE

• Strangler pattern dừng ở tầng API mà không chuyển dữ liệu thì phần khó nhất vẫn ở lại monolith; bắt đầu từ lõi gắn chặt nhất, không phải từ phần dễ cắt.
• Microservices không có chuẩn chung về cấu trúc thì chi phí nằm ở sự khác biệt giữa các service, không ở từng service.
• Một nền tảng cho nhiều thị trường phải giả định "nhiều" ngay từ đầu; thêm cái thứ hai sau là đắt nhất.

Liên quan

• Monolith và microservices — đi và quay lại · Nền tảng nội bộ cho service (đường ray chung)
• Cùng công ty: Mercari 2022 · Mercari 2025
• Cùng hướng quay về module lớn: Shopify 2020 · Segment 2018