Building a Scalable Cross‑Border E‑Commerce Platform: Architecture Lessons and Pitfalls

Introduction

With the rapid development of the Internet, e‑commerce has become deeply popular across China. Wealthy online shoppers are no longer satisfied with domestic platforms such as Tmall, JD, and Taobao; many now purchase directly from overseas sites using dual‑currency credit cards, a practice known as "cross‑border shopping" or "hai‑tao". The early growth of hai‑tao relied heavily on overseas agents who earned large margins by charging service fees and exploiting price differences.

Since 2012, a wave of cross‑border e‑commerce startups (e.g., Yangmaotou, MiTao, MaiYaBaby, LaMaBang, XiaoHongShu) has emerged, targeting the 30‑million‑plus hai‑tao user base. By 2015, major domestic platforms such as Tmall, JD, and Vipshop launched overseas‑purchase channels, intensifying competition.

This article explores technical issues and experiences in building a hai‑tao platform.

Business Background

Although individuals can shop directly on foreign sites, several barriers exist: limited access to multi‑currency credit cards in smaller cities, language difficulties, and the lack of direct shipping to China, which forces users to rely on forwarding services. The entire process can take from half a month to several months, deterring many potential buyers.

Hai‑tao platforms solve these pain points by offering Chinese‑language product pages, domestic‑style checkout, and payment via Alipay or UnionPay, while handling translation, foreign‑currency payment, logistics, and after‑sales support.

Overall Architecture

Layered Structure

1) Access Layer : Provides backend web services for PC browsers, mobile browsers, and native apps.

2) Business Service Layer : Handles registration, authentication, product browsing, cart management, order submission, payment, automatic ordering, and price‑crawling services.

3) Infrastructure Service Layer : Offers SMS, email, full‑text search, image storage, messaging, centralized logging, and distributed caching.

4) Data Storage Layer : Stores structured and file data.

Network Deployment

1) CDN distributes product images, JS, CSS, and HTML.

2) Nginx (master‑slave) ensures high availability, static caching, and reverse proxy.

3) Session Management stores session data in Memcached, supporting non‑sticky sessions.

4) Cache stores product, review, and user attribute data in Redis.

5) Message Service handles internal event notifications.

6) Database uses master‑slave replication with LVS for high availability.

Existing Issues

5.1 Data Concentrated in a Single Database

All product, user, order, and auxiliary data reside in one database instance, making scaling difficult and causing contention when backend bugs increase load.

5.2 Core Business Code Not Encapsulated

Multiple entry points for product management and scattered order‑calculation logic across web, H5, and app modules lead to inconsistent implementations and high maintenance cost.

5.3 Over‑designed, Redundant Code

Excessive plugin‑style web integration, non‑standard Maven structures, and duplicated DAO layers result in hard‑to‑maintain code.

5.4 Abuse of Table Joins and Poor Schema Design

Rapid table proliferation (over 200 tables, with fewer than 20 core tables) and heavy reliance on multi‑table joins cause performance issues; many data could be cached or stored in Redis/MongoDB instead.

Architecture Evolution

6.1 Service‑Oriented Core Business

Introduce a distributed service registry and make core services stateless for easy horizontal scaling.

• User registration, login, and profile become a User Service.

• Product CRUD, SKU updates, and price changes become a Product Service with internal caching.

• Cart management, address updates, order submission, pricing, and status become Cart and Order Services.

6.2 Vertical Database Partitioning

Split the monolithic database into multiple databases: user, product, order, base data, marketing, logistics, content, analytics, and logs, with the first three requiring the highest availability.

6.3 Business‑Level Component Decomposition

Refactor large, monolithic layers into finer‑grained business components, each exposing its own API and managing its own persistence and cache.

6.4 Master‑Multiple‑Slave Database

Move from a single master‑slave to a master‑multiple‑slave setup (three or more slaves) to ensure read‑write separation and higher availability.

Lessons Learned

7.1 Product Data Acquisition

Millions of SKUs cannot be entered manually; a crawler was built to scrape foreign sites, but faced IP bans, captchas, and frequent site redesigns. Translation quality was poor, leading to the adoption of third‑party Chinese product feeds for initial data.

7.2 Order Placement Challenges

Automated ordering faced duplicate orders, rate‑limit blocks, and network latency. A distributed lock prevented concurrent processing of the same user’s sub‑orders, and a monitoring system captured each step for debugging. Combining manual and automated ordering raised success rates above 70% for most sites.

7.3 Logistics Integration Issues

Logistics APIs often failed to provide real‑time tracking, forcing manual polling or periodic crawling, which was costly and slow; some carriers lacked APIs altogether.

7.4 Complex Order Amount Calculation

Order totals must consider product price, foreign shipping, forwarding fees, platform service fees, and promotional discounts, all subject to currency conversion and strict security requirements.

7.5 Matching Users with Products

Cold‑start requires a sizable product catalog; otherwise users cannot find relevant items, leading to low conversion. Solutions include large‑scale crawling, one‑click import of foreign URLs, and leveraging partner data.

Conclusion

The project taught that technology alone cannot solve all problems; close collaboration with product and operations teams is essential. Designing simple, maintainable architectures that meet business needs while allowing future expansion is the core responsibility of an architect.