How We Scaled a Ride‑Hailing Order System: From Single DB to Sharded MySQL

1 Single Database Architecture

Initially the ride‑hailing service used a single SQLServer database, focusing on rapid product delivery.

2 SQL Optimization and Read‑Write Separation

Optimized slow SQL by adding indexes, reducing multi‑table joins, and shrinking large transactions, then introduced read‑write separation, routing writes to the master and reads to replicas.

Read‑write separation reduces master load but introduces replication lag and does not fully relieve write pressure.

3 Business‑Domain Sharding

Split databases by business domain so each service accesses its own database, requiring refactoring of joins into RPC calls and data duplication via message queues.

4 Caching and Message Queue

Added cache and MetaQ to handle order creation, storing order details in cache and asynchronously persisting via MQ, which also smooths traffic spikes.

5 Migration from SQLServer to MySQL

Performed full‑size data migration and incremental sync using MQ, ensuring bidirectional consistency.

6 Self‑Developed Sharding Component

Built a client‑mode sharding library named SDDL, configuring datasource, sharding key, and routing rules.

7 Sharding Strategies

7.1 Passenger Dimension

Used user_id as the sharding key, routing orders to one of four shards based on a hash of the key.

<code>Integer getWorkerId(Long orderId) {
    Long workerId = (orderId >> 12) & 0x03ff;
    return workerId.intValue();
}
</code>

7.2 Driver Dimension

Replicated passenger‑sharded data to driver‑sharded databases via Canal, allowing low‑latency driver queries while keeping a small replication delay.

7.3 Operations Dimension

Synchronized order data to Elasticsearch for complex operational queries.

7.4 Small Table Broadcast

Broadcasted small configuration tables (e.g., city table) to all shards, turning cross‑shard joins into local queries.

8 Smooth Migration

After validating SDDL, migrated from a single‑MySQL instance to the sharded mode using a process similar to the earlier SQLServer‑to‑MySQL migration.

9 Data Exchange Platform

Developed dataLink for incremental synchronization and heavily customized DataX for full‑size sync, addressing the need for real‑time and batch data movement across heterogeneous sources.

10 Conclusion

The architecture evolution, though challenging, strengthened the platform and later benefited other projects such as Luckin Coffee, where the same sharding component and data exchange platform played key roles.