Backend Development 18 min read

Backend Architecture Evolution and Standardization of Didi Ride-Hailing Platform

Didi’s ride‑hailing backend evolved from a monolithic service to a DDD‑split architecture and the DuKang framework, then standardized components, rendering gateways, function access, and logging to solve multi‑terminal inconsistency, complex rendering logic, cross‑process integration, and data visibility, creating a unified cross‑end rendering platform supporting over twenty pages.

Didi Tech
Didi Tech
Didi Tech
Backend Architecture Evolution and Standardization of Didi Ride-Hailing Platform

Due to the inherent complexity of the ride‑hailing business and the constraints of a vertical domain‑driven architecture, the server‑side team of Didi Ride‑Hailing encountered a series of efficiency problems when iterating on server‑side rendering requirements.

1. Backend Architecture Evolution Review

Bayflow Platform 1.0 (2017‑2018) – At this stage the platform was a single monolithic service. To quickly add new categories (e.g., premium, luxury, preferred) the team introduced configuration‑driven and plug‑in mechanisms, allowing rapid onboarding and isolation of category‑specific logic.

Bayflow Platform 2.0 (2018‑2020) – With the rapid growth of categories and personalized features, the system became large and iteration speed dropped. The team applied Domain‑Driven Design (DDD) to split the monolith, reducing overall complexity and eliminating merge conflicts. Functional aggregation and abstraction were added to avoid duplicated development across similar features.

Bayflow Platform 3.0 (2020‑present) – The team built the DuKang framework, separating business logic into a process layer (handling state flow) and a capability component layer (implementing specific functions via strategy pattern and plug‑in mechanisms). This unified approach improves code reuse and maintains consistent standards across services.

2. New Problems and Challenges

Page : the whole screen shown to the user.

Component : an independent functional block on a page.

Template : UI style variations of a component.

Feature : a concrete business scenario (e.g., fleet guarantee, optional car).

Data source : backend service that provides rendering data.

The main challenges identified are:

Multi‑end inconsistency – different terminals (Android, iOS, mini‑program) require separate integration, increasing collaboration cost and causing UI divergence.

Rendering logic management difficulty – a single component may need dozens of display forms, making priority sorting and traffic distribution complex.

Cross‑process feature integration – features that need to appear in many workflow stages must be adapted for each domain service, leading to high integration cost.

Data visibility – disparate logging conventions make it hard to aggregate and analyze data across components.

3. Solution Ideas

Component Standardization – Pages are divided into components with unified UI specifications and data interaction protocols (IDL). All terminals develop components based on these standards, and a component management platform together with a rendering gateway is introduced. The terminal configures which components appear on a page; the rendering gateway fetches component data centrally, reducing per‑terminal backend calls.

Rendering Gateway – Provides two APIs: layout (returns page layout and core component data) and data (fetches data for non‑core components asynchronously). This design improves performance and simplifies terminal rendering.

Component Management Platform – Offers page management, component definition, data‑source registration, and a component panorama view that lets product teams see all pages, components, templates, and associated features.

Function Access Standardization – Builds on the DuKang framework with a fixed rendering flow: context construction → feature filtering → feature decision → feature rendering. Reusable capabilities (e.g., city whitelist, material management) are managed via a function management platform.

Data Standardization – Introduces a unified logging protocol that records page, component, template, and feature identifiers. The data pipeline aggregates logs into a central data warehouse, enabling consistent dashboards and easier data analysis.

In summary, by standardizing components, function access, and data, Didi has built a cross‑end unified rendering platform that currently supports more than 20 pages and continues to expand.

Recruitment Information – The article also includes hiring notices for backend and test engineers, encouraging interested candidates to apply.

backend architectureDidiRide-hailingcomponent standardizationData Standardizationrendering gatewayservice platform
Didi Tech
Written by

Didi Tech

Official Didi technology account

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.