How Dada Built an Automated Business Config Center to Boost Stability and Efficiency

Background

Approximately 20% of entries in Dada’s R&D configuration center are business‑specific configurations. Although a small proportion, they cause high operational cost because they share the same release pipeline as core R&D configs.

Case Example

The logistics platform must manage crowdsourced couriers (riders) and enforce service‑quality training based on complaints. A rider with a complaint generates a work order and must attend a training course; a rider without complaints does not. The training rule depends on dimensions such as city, site, rider type, and complaint reason.

Pain Points and Goals

Pain Points

System stability : Business configs are released together with R&D configs, risking stability.

Robustness : Configs stored as raw JSON lack validation and visual editing.

Efficiency : Long change‑to‑deployment cycle involving many roles.

Data security : All R&D config users can view business configs.

Data analysis : Analysts cannot query config data directly.

Goals

Isolate business configs from R&D configs to reduce release frequency.

Provide visual configuration with built‑in validation.

Enable self‑service configuration for product operations.

Implement fine‑grained permission control.

Achieve high availability via a decentralized client.

Support real‑time notification of config changes.

Expose config data for analyst queries.

Solution Architecture

The custom center consists of a web portal for configuration management and a client library ( dada-biz-config) for reading configurations. Apollo is used as the underlying store for its operational maturity, stability, decentralized deployment, and open API support.

Configuration Creation Workflow

Creating a configuration involves three visual steps:

New Configuration : Click “Add” on the configuration list page.

Define Columns : Specify columns (e.g., city, site, rider type, complaint type, order days, training course) which become the table header.

Configuration Details : Add rows using a visual form; each column renders an appropriate front‑end component for data entry.

After creation, users can edit, delete, or view operation logs.

Permission Management

Owners and administrators can assign read/write permissions to specific users.

Column Types and Business Components

Three column‑type categories are supported:

Custom : Basic types such as boolean, string, number, decimal, date.

Predefined enums : Users define an enumeration; the UI renders a dropdown.

Business components : Pull data directly from existing business tables (e.g., city, site) to handle high‑cardinality dimensions.

Default Configuration & Combination Deduplication

A fallback default configuration can be set for cases where no specific rule matches.

Columns can be marked for unique‑key combination to ensure only one configuration matches a given dimension set (e.g., city + rider type + complaint type).

Client API

The dada-biz-config library provides three retrieval methods: getBizConfigsByKey: Retrieve all configuration data. getBizConfigsByColumns: Filter by column values (e.g., all configs for Shanghai). getBizConfigByUniqueIndex: Retrieve a single config based on the unique‑key combination.

Results

Since launch (up to September), the center has integrated 296 configurations, added 80 new configs in two months, and processed over 600 modifications, saving an estimated 200+ person‑days. It handled the 2021 “618” traffic peak without incidents.

Performance: steady request volume of ~7 k QPM with average latency around 0.1 ms, demonstrating high scalability.

Future Plans

Break Apollo’s single‑key length limit to store larger configurations.

Enable cross‑environment configuration synchronization (dev → QA → prod).

Integrate more business components to support additional scenarios.