Building and Optimizing a Cross‑Border E‑Commerce Data Platform: Architecture, Challenges, and Protonbase‑Based Solutions

Founded in September 2020, Xide International quickly grew into a leading cross‑border e‑commerce company serving over 130 countries with multi‑language support and a global creative center in Los Angeles, backed by more than 500 staff across several continents.

The talk is organized into four parts: (1) Business architecture overview, (2) Problems faced by the current architecture, (3) Architecture optimization strategies, and (4) Value generated by the optimizations.

1. Business Architecture Overview

The front‑end layer includes iOS and Android apps. The traffic‑entry layer consists of edge computing, Apisix gateway, CDN, and behavior‑risk control services that limit request frequency, detect crawlers, and prevent malicious code. The business layer covers search, recommendation, marketing, product, and especially logistics, where a wide range of international shipping options are matched to users.

The shopping‑cart module allows unauthenticated add‑to‑cart, leading to massive stale data that required a custom solution. Payment handling supports many overseas payment methods and includes order‑risk control to detect credit‑card fraud and high‑risk orders. The service‑governance layer provides monitoring, quality assurance, and alerting, while the foundational layer offers unified internationalization (I18n) for currency, exchange rates, and translations.

2. Problems Encountered

Rapid business growth outpaced the data‑analysis team, causing long turnaround times for ad‑hoc queries. Micro‑service‑driven sharding split data across four databases (order, payment, cart, product), resulting in data redundancy and difficulty performing cross‑database joins, sometimes taking up to five working days.

3. Architecture Optimization

The solution involved four steps: (a) Consolidate sharded tables to enable joint queries, (b) Provide high‑performance unified queries, (c) Enable real‑time multi‑shard synchronization (currently supported only for daily tables), and (d) Support schema evolution from source databases.

Using Protonbase, the team merged over 30 tables—including the fragmented cart tables—into a single warehouse, allowing direct SQL queries without involving the data‑analysis or engineering teams. Query latency dropped from days to under ten minutes.

Further improvements removed the read‑only replica by routing read traffic through Protonbase, reducing infrastructure cost and simplifying the data pipeline.

4. Value of the Optimizations

Query and data‑extraction time reduced from five days to ten minutes, greatly increasing business agility.

Data access path streamlined to only two copies (primary DB and Protonbase), accelerating response times.

Overall costs lowered, including communication overhead, data‑extraction implementation, and replica infrastructure expenses.

The presentation concludes with thanks to the audience.