How to Build a Mini Didi: Scalable Ride‑Hailing Architecture Explained

1. Macro View: Domain‑Driven Design

Before writing code, the business domain is broken down. The core of a ride‑hailing service is dynamic scheduling, represented by a "dispatch brain" placed at the center of a hexagonal architecture.

Decoupling necessity : Orders, payments, and messages are split into independent micro‑services, ensuring fault isolation—e.g., if the payment service fails, ordering and driver assignment continue.

Core link : User request → dispatch brain calculation → driver lock → message delivery. This path must guarantee ultra‑high availability.

2. Traffic Funnel: Layered Architecture

To support tens of millions of daily active users, a clear multi‑layer skeleton is required.

Gateway (access) layer : Acts as a "front door" with routing, rate‑limiting (token‑bucket) and authentication, protecting downstream services from traffic spikes.

Infra vs. business layer : Common capabilities such as LBS calculations and Netty push are provided as infrastructure services; business logic (car‑pool, premium rides) calls these APIs, improving development efficiency.

3. LBS Engine: Redis GEO for Million‑Driver Proximity

Traditional MySQL range queries ( WHERE latitude > ? AND longitude < ?) become inefficient at million‑scale, causing index collapse.

Solution: use Redis GEO (based on GeoHash) to map 2‑D coordinates to a 52‑bit integer and store them in a sorted set.

Dimensional reduction : GeoHash converts latitude/longitude into a single integer.

Efficient retrieval : GEORADIUS command queries drivers within a 3 km radius in O(log N) time and returns them sorted by distance.

4. Concurrency Challenge: Distributed Lock

In dispatch or抢单 modes, the same order may be pushed to multiple drivers simultaneously. To avoid overselling, a distributed lock is introduced.

Mutual exclusion : Redis SETNX (Set if Not Exists) ensures only the first request acquires the lock; subsequent attempts are rejected.

Dead‑lock fallback : Each lock is given a TTL so that a crashed node releases the lock automatically, preventing system blockage.

5. Real‑Time Push: Netty Long‑Lived Connections

After a driver successfully grabs an order, the system must instantly notify them. HTTP polling is too slow and wasteful.

Solution: WebSocket + Netty establishes a full‑duplex long connection.

IO model : Netty’s NIO (non‑blocking) combined with Epoll allows a single machine to handle over 100 k concurrent connections.

Protocol optimization : Using Protobuf instead of JSON reduces payload size, lowers bandwidth consumption, and improves delivery in weak networks.

6. Data Governance: Hot‑Cold Separation

Order and trajectory tables quickly exceed 20 million rows, degrading MySQL performance.

Hot data (MySQL) : Recent three months of orders stay in MySQL with ShardingSphere for sharding and transaction support.

Cold data (HBase/TiDB) : Historical orders older than three months are migrated via DataX to a cheaper, scalable NoSQL store.

Trajectory data (MongoDB) : High‑write, low‑read trip coordinates are stored in a MongoDB sharded cluster, which fits the write‑heavy pattern without strong transaction needs.

7. Summary

Designing a mini Didi boils down to trading space for time and applying layered governance. The key techniques are:

Redis GEO for fast spatial search.

Netty long‑connection for low‑latency real‑time messaging.

Distributed locks to prevent resource contention under high concurrency.

Hot‑cold data separation to control storage costs at massive scale.

Mastering this combination equips engineers to tackle most LBS‑type system‑design challenges.