How to Design a Scalable Ride‑Hailing System: From Requirements to Real‑Time Dispatch

1. Introduction

1.1 Typhoon Impact

Shenzhen was hit by Typhoon Surra on September 1, triggering a level‑1 emergency response. From 4 pm the city enforced “five stops”: work, business, market, school, and traffic were halted, forcing many employees to leave early or work from home.

Images show workers leaving early, staying late, and remote workers at home.

1.2 Ride‑hailing Collapse

At around 4 pm public transport was overloaded, and when people tried to book a Didi ride they faced a queue of 142 pending orders, dramatically increasing waiting time.

The author reflects on how a ride‑hailing platform could better prepare for such emergencies.

2. Designing a Ride‑Hailing System

2.1 Requirement Analysis

The core function is to transmit passenger orders to nearby drivers, who pick up the passenger and complete the trip. Drivers receive a commission (70‑80 %), and passengers can use third‑party credit (e.g., Alipay) for password‑free payment after the ride.

Both passengers and drivers have separate registration and login modules.

2.2 Overview Design

The system follows an “Internet + shared resources” model, matching vehicles with multiple passengers. Two separate mobile apps are required: one for passengers, one for drivers.

Passenger View

After registering, a passenger selects origin and destination, then the request passes through a load balancer, an HTTP gateway cluster, and finally reaches the ride‑hailing microservice.

The gateway also calls the user service to retrieve profile data.

Driver View

Drivers register, enable location services, and maintain a TCP long‑connection that periodically (every 3‑5 seconds) reports latitude, longitude, and heading to the platform.

Using a TCP long‑connection avoids the latency and overhead of repeated HTTP requests.

Order Reception

The gateway acts as a registration center, performing security filtering, rate limiting, and request forwarding. It creates an order record, then publishes the order to a message queue (e.g., RabbitMQ) for driver assignment.

Order Assignment

The assignment service consumes the queue, marks the order as “assigning”, and pushes the order to an SDK that retrieves driver locations, selects the most suitable driver, and sends the order via a message‑alert system over TCP.

Reject and Grab

Drivers may reject orders; repeated rejections lower the driver’s assignment weight. The system can also allow drivers within a geographic radius to “grab” the order, changing the status to “dispatched”.

2.3 Detailed Design

Long‑Connection Advantages

Long connections provide higher connection success rates, lower latency, and stable message delivery compared with short‑lived HTTP requests.

Long‑Connection Management

Driver apps maintain a stateful TCP channel; the server maps each app to a connection using Redis. If the connection drops, the app re‑registers via a Zookeeper‑stored address.

Geohash Address Algorithm

Passenger and driver coordinates are encoded into a GeoHash string, stored in Redis. The algorithm quickly retrieves drivers within the same rectangular area for dispatch.

Experience Optimization

Distance Algorithm

Simple Euclidean distance is insufficient; the system should consider road distance, driver heading, and pickup point to estimate arrival time.

Order Priority

Cancellation behavior, driver reputation, and passenger profile are used to compute a credit score that influences dispatch priority.

4. Summary

4.1 Ride‑Hailing Market

The global ride‑hailing market is worth billions of dollars, dominated by Didi, Uber, and Grab. Platforms earn revenue by taking a 10‑30 % commission on each trip.

4.2 Current Situation

Regulation is tightening; platforms must retain communication records and comply with local safety standards, which will shape future development.