How Xianyu Scaled to Millions of DAUs: Inside Its Architecture Evolution

Xianyu Business Background

Founded in 2014 in an Alibaba tea room, Xianyu grew from zero to tens of millions of daily active users in five years, witnessing the shift of second‑hand goods from offline to online. This rapid growth required continuous business‑architecture adjustments.

Market Characteristics

Xianyu is a high‑value‑for‑price second‑hand marketplace where users can obtain higher‑valued items at the same cost, such as game cartridges and LEGO. Trust cost is a key challenge because most second‑hand items lack after‑sales service and have subjective residual value assessments.

Ways to Expand Market Space

Reduce newcomer onboarding cost.

Improve matching efficiency.

Differences from Taobao

Sellers are non‑professional individuals with weak profit motivation.

Lightweight product publishing to ensure market supply.

Products have sparse structured information and no historical behavior data.

Architecture Evolution – Trial Phase

During the trial phase the core business problem was exploring a suitable commercial model, while the architectural focus was on fast response and rapid feature rollout, accepting a slight reduction in online quality for speed.

URL Router: route all requests to an H5 link and use URI schema redirection; if native is unavailable, fallback to H5.

Switch Center: control page entry, versioning, and parameter changes via feature switches.

Poplayer: deploy H5 containers on native pages without a new release, enabling on‑demand activities.

Architecture Evolution – Development Phase

The business needed to validate emerging models and scale quickly. Architectural concerns shifted to efficiency and building capabilities for verification.

Protocol and tool automation, using MBaaS to provide unified data sources (products, users, search, interaction) so front‑end can fetch needed data with a SQL‑like description, reducing backend API proliferation.

Component library for UI reuse, with components linked to backend services for data handling.

Architecture Evolution – Platform Phase

As Xianyu’s product lines expanded, the platform needed to support third‑party participation while maintaining stability.

Core business problem: enable ecosystem partners to contribute to the sharing‑economy platform.

Architectural focus: extensibility, business isolation, and platform‑level capabilities.

SWAK framework: separates immutable (what) from mutable (how, who) parts, providing remote‑call extension points for application‑level isolation, improving development and operational efficiency.

Cloud‑Native Integration

To achieve a unified development experience, Xianyu adopted a Dart‑centric stack:

Flutter unified iOS and Android client development.

Flutter + Dart extended to the server side, replacing Java with Dart for backend services.

FaaS (Dart runtime) and Nexus framework bridge client and cloud, allowing a single developer to cover end‑to‑end business logic.

This integration reduced resource duplication, improved collaboration (1 + 1 < 2), enabled full business closure on the client side, and allowed domain teams to focus on core capabilities.

Benefits and Outcomes

Resource balancing: one Flutter codebase replaces separate iOS/Android implementations.

Collaboration efficiency: unified protocols eliminate cross‑team coordination overhead.

Business closure and talent growth: developers can own the entire product lifecycle.

Framework sinking: Nexus connects UI and logic, enforcing UI‑only responsibilities on the client.

Conclusion

Architecture evolves iteratively; there is no single silver‑bullet solution. Effective design must align with current business characteristics and core problems, continuously iterating to support scaling and complexity.