グローバルなメルカリの検索バックエンド設計と検索基盤拡充 (Search backend for the Global App and extending the search platform)

Mercari · 2025 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Một bài trong series Global App (ngoài sheet). Bối cảnh: Mercari 2025. Tác giả từng thiết kế hệ search của Mercari Nhật 7 năm trước và vận hành nền tảng Elasticsearch nội bộ (EaaS).

Bối cảnh

• Search của Global App viết lại từ đầu. Yêu cầu tối thiểu: 50 nước trong 3 năm; tổng listing tích luỹ 4 tỉ (9/2025). Khác search Nhật ở ba điểm: đa ngôn ngữ; phải xử lý cả item model (C2C, mỗi kết quả một món) lẫn product model (B2C, một kết quả có nhiều biến thể); và tự chỉnh kết quả độc lập với search Nhật (ưu tiên, nguồn lực của hai bên không kéo nhau).
• Search Nhật chạy Elasticsearch trên EaaS: nền tảng nội bộ dựng trên ECK, gần như mọi dịch vụ search trong tập đoàn chạy trên đó. Nhưng logic search của Nhật (synonym, phân tích hình thái tiếng Nhật, tuning) nằm trong các microservice Go, gắn chặt vào nghiệp vụ Nhật; plugin Elasticsearch (Java) hầu như không ai viết vì ít engineer Java.

Thay đổi chính

• Dùng dịch vụ managed để ra nhanh, có kế hoạch quay về tự vận hành: chọn Vertex AI Search for Commerce (VAIS:C) vì managed, tính tiền theo request (không traffic thì không tốn), đa ngôn ngữ, nhận sẵn product model có biến thể, endpoint toàn cầu. Điểm vướng duy nhất là chi phí, nên chiến lược là bắt đầu nhỏ trên VAIS:C, chuyển sang Elasticsearch khi traffic lớn tới mức không còn có lời, và dùng thời gian đó chuẩn bị phía Elasticsearch.
• A/B test cho thấy với dữ liệu sản phẩm và event người dùng của Mercari (phải chuyển từ hệ event riêng sang schema GA4), kết quả kém search Nhật và vài yêu cầu khó đáp ứng; vẫn chọn VAIS:C cho bản đầu sau khi hai bên chấp nhận rủi ro.
• Thiết kế backend mới, sửa các điểm tác giả thấy sai ở hệ cũ:
  • API theo data model, không cố tổng quát hoá (một endpoint "search Product").
  • Cơ chế plugin móc vào tiền xử lý và hậu xử lý query, thay cho rất nhiều if rải trong code search Nhật.
  • Tách lớp trừu tượng khỏi phần cài đặt engine để chạy được cả VAIS:C lẫn Elasticsearch; theo tác giả vẫn sẽ làm vậy kể cả không có yêu cầu này vì engine (nhất là vector) thay đổi liên tục.
  • BFF có chỗ cố định: ở hệ microservice cũ, đội search không biết ai gọi API search rồi đưa cho khách.
• Mở rộng nền tảng search: product owner muốn dùng lại các tính năng search của Nhật. EaaS chỉ cung cấp Elasticsearch, không chịu trách nhiệm tái sử dụng tính năng trên nó (đội quảng cáo trước đó cũng tưởng dùng EaaS là có chất lượng search như Nhật). Kết quả sau nhiều thảo luận: dựng một lớp mới trên EaaS tách dần từng tính năng tái sử dụng được, với hai nguyên tắc: nền tảng không hạn chế quá mức phần mềm mã nguồn mở bên dưới; mỗi domain dùng được độc lập, mở cho đóng góp qua plugin để tránh "chính trị" ưu tiên. Hiện search Global App chạy lai VAIS:C và lớp mới trên EaaS.

Vì sao

• Tái dùng Elasticsearch là cách duy nhất cân được doanh thu và chi phí với khối dữ liệu toàn bộ Nhật, nhưng việc dọn đường (đa ngôn ngữ, độc lập, nhân lực) quá lâu so với ngày ra mắt.
• Nền tảng chỉ cấp engine thì không tạo ra tính năng dùng lại được; tính năng nằm trong service của một sản phẩm thì sản phẩm khác không lấy được.

Bài học cho SWE

• Managed để ra nhanh, kèm điều kiện chuyển (traffic, chi phí) và lớp trừu tượng engine ngay từ đầu.
• Nền tảng hạ tầng (engine-as-a-service) khác nền tảng tính năng; nếu không ai sở hữu lớp tính năng dùng chung, mỗi sản phẩm mới phải dựng lại hoặc đi mượn code.
• Plugin hook cho query thay cho if theo trường hợp là mẫu quen của search (Elasticsearch, Solr, Galene).

Liên quan

• Hạ tầng tìm kiếm · Nền tảng nội bộ cho service (đường ray chung)
• Cùng series: Mercari 2025 · Mercari 2025 · Mercari 2025
• Gom tính năng search thành framework có plugin: LinkedIn 2014 · Grab 2022