How Youzan Scaled Order Search: Hot‑State Indexing and AKF Expansion

Background

Two years ago a three‑life three‑ambush architecture for Youzan order management was introduced. Since then the architecture has evolved, and the current AKF order search architecture is reviewed.

Order Migration

Buyer order migration: when a new user becomes a followed user, the mock buyerId is replaced by a real buyerId.

Seller order migration: when a shop model upgrades (e.g., from a micro‑mall to a retail chain), orders from the original store are migrated to the new store.

New Challenges

Data volume grew to billions of documents, causing slow queries and high resource consumption.

Many low‑frequency custom search fields were added to the main index, inflating its size and further degrading performance.

Response

3.1 Splitting for Scalability

A multi‑dimensional architecture was introduced with three search dimensions:

B‑side single‑store search (merchant manages orders of a single store).

B‑side multi‑store search (merchant chain manages orders across stores).

C‑side cross‑store search (buyer manages orders across multiple stores).

Because both B‑side and C‑side require cross‑shard queries, hot and cold data are separated first.

3.1.1 Hot‑State Index

Monitoring shows that order‑status searches account for about 53 % of traffic; roughly half of those target hot‑state orders (pending payment, pending shipment, pending group, pending acceptance, shipped). Hot orders remain stable at a few tens of millions, handling roughly half of total search traffic while keeping the index size manageable.

3.1.2 Time‑Sharded Index

Terminal‑state orders are stored in time‑based shards. The sharding granularity evolved from half‑year to quarter and now to month. This keeps each shard size reasonable and allows queries to be limited to recent periods (e.g., the last six months).

3.2 Expansion Criteria – AKF Expansion Cube

The cube defines three scalability axes:

X‑axis : data/service cloning (master‑slave clusters). Lowest cost and simplest to implement; suitable for early‑stage, low‑complexity scenarios.

Y‑axis : functional decomposition (separate transaction, product, member services). Improves fault isolation and response time; higher cost; suited for complex, large‑scale business.

Z‑axis : priority‑based segmentation (buyer vs. seller, high‑growth user groups). Highest cost but provides greatest scalability and risk isolation; used when user growth is exponential.

The current architecture expands along all three axes.

3.3 Current State

Extensible Index Field Design

Using a list<String> field allows dynamic addition of custom search keys without changing the index mapping. Each merchant supplies key‑value pairs, and the search layer treats them uniformly.

Lightweight Statistics via Search

Elasticsearch returns the total hit count for any query. By formulating statistical queries directly against the index, arbitrary dimensional counts can be obtained instantly, eliminating offline aggregation pipelines and reducing failure points.

Outlook

After four years the system supports configurable search, on‑demand statistics, and reliable synchronization. Future work will focus on further scaling the Youzan search platform.