Scaling Dada's Delivery Platform: From Simple Architecture to Read/Write Separation, Vertical and Horizontal Sharding

Dada, founded in May 2014, quickly grew to handle nearly one million daily deliveries across 37 Chinese cities, creating massive read and write pressure on its backend systems.

Technical Background

The service consists of two core flows: merchants placing orders and couriers accepting and delivering them. Early traffic reached billions of reads per day, with read QPS far exceeding write QPS (approximately 30:1).

Initial Architecture: Simple Direct Design

To move fast, Dada used public cloud services, Python for application code, and a single MySQL instance accessed by all services.

Mid‑stage Optimization: Read/Write Separation

Rapid growth caused MySQL CPU and I/O to saturate, with slow queries increasing from hundreds to tens of thousands per day. Dada introduced master‑slave replication and routed write requests to the master and read requests to one or more slaves.

After separation, CPU and I/O dropped below 5% and slow queries nearly vanished.

New Issues: Master‑Slave Lag

During peak periods, the master‑slave delay sometimes reached up to 10 seconds, causing "read‑after‑write" inconsistencies. Monitoring with SHOW SLAVE STATUS and tuning MySQL parameters, hardware, and SSD storage helped mitigate the lag.

Write Performance Degradation

Even with read separation, write latency grew as insert operations took over a second, driven by high I/O usage and large tables (e.g., a log table with ~100 M rows using UUID primary keys).

Vertical Partitioning of the Master

Dada split the monolithic database into business‑specific databases, reducing I/O usage to ~22 % and response times to under 2.33 ms. This required code changes to avoid cross‑database joins.

Preparing for the Future: Horizontal Sharding

To handle ever‑growing tables and write load, Dada adopted sharding. After evaluating city‑based versus order‑ID‑based splitting, they chose order‑ID sharding for even data distribution.

Sharding Architecture

The system now has three layers: an application layer, a data‑access layer that abstracts sharding and caching, and a data layer where each shard is a separate MySQL instance.

ID Generation

A 64‑bit ID scheme inspired by Instagram was implemented: 36 bits timestamp, 13 bits shard identifier, and 15 bits per‑shard auto‑increment sequence, ensuring global uniqueness and monotonic ordering.

Conclusion

Early rapid development favored simple, cloud‑based solutions, but scaling pressures forced Dada to adopt read/write separation, vertical partitioning, and finally horizontal sharding with a robust ID generator, illustrating the necessity of proactive architecture upgrades for high‑performance, high‑availability services.