Integrated Commerce and our Merchant Center rebuild
Bài tóm tắt Zalando 2016 2. Tăng trưởng Độ khó: Cơ bản
Zalando · 2016 · 2. Tăng trưởng · Độ khó: Cơ bản — bài gốc
Bài viết ở giai đoạn kế hoạch: mô tả hướng làm lại, chưa có kết quả hay số liệu.
Bối cảnh
- Zalando muốn bán được mọi món hàng thời trang "có ở đâu đó": nối kho e-commerce của thương hiệu/nhà bán lẻ khác và kho của cửa hàng truyền thống (số hoá tồn kho, hiển thị online, tính tới nhận hàng tại cửa hàng).
- Partner Program hiện có (2016) dựa trên Java và SOAP, chỉ có interface backend: đối tác không có giao diện tự quản lý, mọi việc đi qua frontend nội bộ của Zalando. Kho đối tác nối qua bên trung gian (Anatwine, Tradebyte) giữa ERP/shop của đối tác và Zalando; cửa hàng truyền thống nối qua interface riêng do team Fashion Connector ở Helsinki làm.
Thay đổi chính (kế hoạch)
- Thay bằng interface chung theo hướng chuyển từ shop monolith sang microservice của Zalando: REST trên AWS; backend Scala + Akka (actor, Akka-HTTP cho REST API); RDS PostgreSQL cho dữ liệu quan trọng.
- Frontend cho đối tác (AngularJS, TypeScript, chia module để team tự deploy) để đối tác tự đưa sản phẩm lên, đặt giá, tồn kho, vị trí, tự xử lý đơn, trả hàng và tài chính; hoặc gọi thẳng API Merchant Center.
- Dùng lại các thành phần lõi của nền tảng để bán qua nhiều kênh (Zalando Shop, Lounge, ZipCart).
Vì sao
- Theo Zalando: đối tác tự chủ thay vì phụ thuộc Zalando để tích hợp; AWS làm deploy phiên bản mới dễ hơn và dễ scale; Scala/Akka hợp với hệ bất đồng bộ, phân tán.
Bài học cho SWE
- Tích hợp chỉ có backend buộc mọi việc của đối tác đi qua người nội bộ; mở API + giao diện tự phục vụ là cách bỏ nút thắt đó.
- Làm lại một hệ tích hợp thường đi cùng đợt chuyển kiến trúc lớn của công ty (ở đây là monolith → microservice).
Liên quan
Được nhắc tới trong
Chủ đề (1)
Công ty (1)