How Dingdang Kuaike Achieves 28‑Minute Drug Delivery: The Underlying Tech Architecture

Song Zilong, General Manager of the Product R&D Division at Dingdang Kuaike, shares a decade‑long technical journey that enabled the company to promise 28‑minute drug delivery. He began his career in telecom, e‑commerce and cross‑border platforms before joining Dingdang Kuaike in 2015.

Architecture Evolution

In 2016 the team migrated from a monolithic system to micro‑services to improve high‑availability and horizontal scalability. Business domains such as user‑membership, product‑merchant, order, inventory‑picking, dispatch, marketing, and payment were identified and split, with the order and fulfillment domains prioritized because they faced the most frequent expansion pressure.

The core strategy for distributed transactions was eventual consistency. Reliable messages, compensation logic and idempotent design were used; strong‑consistency scenarios were kept within a single service‑single database, while cross‑service interactions relied on event‑driven state machines.

To prevent service snowballing, the team introduced circuit‑breaker, degradation, rate‑limit, timeout and isolation mechanisms. The main order‑picking‑dispatch chain was always protected, ensuring that even during pandemic spikes the primary flow remained stable. Non‑core functions such as recommendation, marketing display and comments were set to auto‑degrade.

Intelligent Scheduling Core

In 2017 an intelligent scheduling team was formed to replace manual, experience‑based dispatch with a real‑time algorithm. For each incoming order the system evaluates multiple dimensions—order location, picking time, rider location, traffic, and the rider’s current load—and continuously re‑optimises as orders and rider capacity change at millisecond granularity.

During peak periods the algorithm merges orders to reduce empty runs, balances store load, and dynamically adjusts rider assignments. When capacity is insufficient or adverse weather occurs, the system falls back to pre‑planned measures: historical hotspot prediction, schedule adjustments, crowdsourced riders, dynamic electronic fences, and priority handling of urgent prescriptions. Strategies are communicated to users and riders in real time to avoid perceived delays.

City‑Specific Model Adaptation

Because population density and traffic vary across cities, the scheduling framework combines a base model with city‑level parameters and store‑level parameters. Parameters such as fence size, rider capacity and weight coefficients are calibrated per city. New cities undergo a cold‑start using historical orders, geography and traffic data, then refine the model with live fulfillment data.

Database Sharding and Migration

In 2020 the core Oracle database was split into multiple MySQL shards to cut commercial database costs and to support IDC migration from Beijing to Wuxi. The migration posed two major risks: data consistency across heterogeneous systems and business interruption for the O2O platform.

To mitigate these, the team performed domain‑driven sharding—splitting by business boundaries (order, member, product, payment, promotion) rather than by tables—allowing phased migration with acceptance tests at each stage. Critical tables were sharded using Sharding‑JDBC, while heavy read traffic from order queries was off‑loaded to Elasticsearch. Data synchronization was handled by Alibaba’s open‑source Yugong tool, which performed Oracle‑to‑MySQL sync followed by post‑migration verification; no dual‑write was used.

Migration windows were scheduled during low‑traffic night periods, with rollback plans and pre‑defined fallback points. Although the migration required a brief service pause, the risk was controlled and the result was a successful transition to a lower‑cost, sharded MySQL architecture.

Hybrid‑Cloud Multi‑IDC Deployment

From 2021 the architecture adopted a dual‑IDC plus multi‑cloud setup, achieving real‑time cross‑region data backup and eliminating single‑datacenter failure risk. The goal shifted from merely removing a single‑point‑of‑failure to improving availability and reducing hardware/ops costs. By 2025 the entire infrastructure moved to a cloud‑native, multi‑AZ environment, addressing challenges such as data migration latency, gray‑scale cut‑over, and cloud‑cost governance.

R&D Management and FDE Innovation

The role expanded from pure backend engineering to overseeing product, algorithm, testing and overall technology line. Management emphasis moved from system stability to business value, requiring cost‑benefit analysis for each architectural upgrade. The team adopted an FDE (Fast‑Delivery‑Engineering) model to deliver quick, business‑centric solutions without disrupting the core transaction flow, while balancing resource allocation among daily operations, AI projects and innovation pilots.

AI Full‑Chain Business Integration

AI capabilities are being built as a reusable platform. Models, knowledge bases, workflow orchestration and compliance policies are abstracted as shared services accessed via the MCP gateway, which provides unified permission, audit and governance. New AI health scenarios—symptom analysis, medication consultation, health knowledge—will be added as separate domains that interact with existing order, fulfillment and member services through well‑defined interfaces, avoiding changes to the core chain.

Overall, the technical evolution—from monolith to micro‑services, from single‑IDC to hybrid‑cloud, from manual dispatch to AI‑driven scheduling, and from Oracle to sharded MySQL—has created a resilient, scalable foundation that supports Dingdang Kuaike’s 28‑minute delivery promise while enabling future AI‑driven health services.