Design and Architecture of DiDi's Pricing System

Introduction

Pricing is a critical component of ride‑hailing services. At DiDi, different business lines (e.g., Didi Taxi, Didi Express, Qingju bike sharing) use various pricing models such as distance‑based, time‑based, time‑slot, one‑price, and manual entry. Over years of exploration, DiDi has built a powerful pricing system that serves all its business lines and provides solutions for price‑related problems across travel scenarios.

Value to Users

The system delivers accurate price estimates to users before a trip, real‑time billing during the ride, and detailed final invoices. Accurate pricing influences user decisions because travel services are highly customized; factors like start/end points, route congestion, and travel duration affect the final fare.

Value to Business

The pricing system supports demand‑supply balancing (e.g., seasonal price adjustments), offers a unified middle‑platform for multiple lines (ride‑hailing, car‑sharing, international services, etc.), and provides capabilities such as city‑level pricing, fence‑based pricing, open pricing, and price‑rights management. This reduces development duplication and improves cost efficiency.

Technical Architecture

The system is a distributed architecture composed of several layers:

InRouter (Gateway) – Unified entry point with driver‑ID consistent hashing and in‑memory caching for performance and fallback.

Application Layer – Stateless core pricing module handling estimate calculation, configuration lookup, trajectory processing, and fee aggregation. It can be horizontally scaled on DiDi Cloud.

Config Module – Highly flexible configuration platform (built on Apollo) that abstracts city, fence, scenario, open pricing, price rights, i18n, and fee definitions. Provides self‑service UI components and RBAC for permission isolation.

Module Layer – Basic infrastructure components (service discovery, distributed config, metrics, tracing, RPC framework).

Service Layer – Over ten independent services (e.g., ETA, Cratos, Dealer, Fence) that decouple functionality, improve stability, and enable rapid iteration.

Data Layer – Uses Codis (distributed Redis) for hot data, Fusion (DiDi’s NewSQL) for persistent storage, MySQL, Elasticsearch, HDFS, and DDMQ for messaging. Codis operates in dual‑active data centers with consistent hashing to ensure high availability; Fusion serves as a durable fallback.

Challenges

Stability – Measured by unavailable time and incident count. Practices include strict code‑review processes, on‑call rotation, weekly stability retrospectives, and defensive programming (dependency isolation, degradation strategies).

Accuracy – Time is calibrated server‑side and reported per‑second; mileage is calculated using spherical distance rather than straight‑line distance, with GPS drift handling and point validation.

Efficiency – Open pricing and price‑rights modules enable rapid, configuration‑driven feature rollout, supporting hundreds of fee items without custom development. This reduces iteration latency and operational cost.

Open Pricing & Price Rights

Open pricing separates business‑specific interventions from the core engine, allowing plugins to adjust bills for insurance, cross‑city fees, subsidies, etc. Price‑rights provide multi‑dimensional feature identification (product line, vehicle type, scenario, region, etc.) and diverse intervention methods (add/remove fees, coefficients, one‑price, discounts). All changes can be deployed within minutes via configuration.

Recruitment Notice (Non‑technical)

The article concludes with a call for backend engineers to join DiDi’s intelligent middle‑platform team, providing contact information for applications.