How LeTV Scaled Its Order System to One Million Transactions per Second

Background

High‑traffic flash‑sale scenarios demand an order system that can sustain both high throughput and strong stability. LeTV (Le Sheng) has repeatedly achieved top performance in large‑scale e‑commerce events, making its architecture a valuable reference for building million‑TPS order processing pipelines.

Sharding and Database Partitioning

LeTV adopts a two‑dimensional data split:

Table‑level sharding : a single logical table is divided into multiple physical tables based on a sharding key (e.g., user ID, order ID).

Database‑level sharding : each table shard is placed on a distinct database instance, spreading I/O and CPU load across many nodes.

During capacity expansion, data migration scripts move existing rows to newly provisioned shards while keeping the service online. This approach enables linear growth of storage and compute resources.

Distributed ORM – Mango

To avoid embedding sharding logic in every service, LeTV built a middleware called Mango , a distributed Object‑Relational Mapping (ORM) framework. Mango provides:

Transparent routing of read/write operations to the correct shard.

Built‑in read‑write separation, allowing reads to be served from replica clusters.

Connection‑pool management and retry mechanisms that improve latency and fault tolerance.

Unified API so application code does not need to handle shard keys explicitly.

Benchmarks reported by LeTV show that Mango reduces average query latency by 20‑30 % compared with hand‑crafted sharding code and simplifies maintenance.

Order ID Design with Snowflake

LeTV generates order identifiers using the Snowflake algorithm, which produces 64‑bit, globally unique, time‑ordered IDs. The structure typically includes:

+----------------+----------------+----------------+
| 41‑bit timestamp | 10‑bit machine ID | 12‑bit sequence |
+----------------+----------------+----------------+

Key advantages:

IDs are sortable by creation time, facilitating range queries.

Collision risk is eliminated without a central ID service.

When combined with sharding, the timestamp component can be used as part of the shard key, but care must be taken to avoid precision‑redundancy problems (e.g., overlapping time windows across shards).

Cluster Splitting (Third Dimension)

Beyond table‑ and database‑level sharding, LeTV introduces a third dimension: independent order‑system clusters. Each cluster contains its own full set of sharded tables and databases, and clusters are isolated from one another.

Routing logic examines specific fields of the user ID (such as the high‑order bits) to decide which cluster should handle a request. This deterministic routing ensures that a given user’s orders always reside in the same cluster, preserving locality while allowing the overall system to scale horizontally.

Scaling Results

By combining two‑dimensional sharding, the Mango middleware, Snowflake IDs, and cluster splitting, LeTV achieved:

Baseline throughput of ~100 k transactions per second (TPS) with a single sharding layer.

Linear scaling to >1 M TPS after adding multiple clusters and routing traffic based on user attributes.

Stable latency under peak load, with 99th‑percentile response times remaining under 200 ms.

Key Takeaways

Sharding alone does not guarantee unlimited scalability; careful cluster design and routing are essential.

Middleware such as Mango abstracts sharding complexity, improves performance, and eases maintenance.

Snowflake‑style IDs provide collision‑free, time‑ordered identifiers suitable for high‑throughput order systems.

Deterministic routing of requests to independent clusters based on user‑ID fields enables the system to reach million‑TPS levels.