Bilibili Configuration Center (Config & Paladin): Architecture, Features, and Performance

The article introduces the motivation behind building a configuration center at Bilibili, describing how the evolution from monolithic applications to micro‑service architectures creates new challenges for configuration management, such as scattered config files, difficulty of gray releases, and redundancy across services.

It then outlines the first generation, Config (v1), launched in 2017. Config provides a unified management UI, environment‑based permission isolation, public configuration, and search capabilities. High availability is achieved by broadcasting updates via an Admin component, while data is persisted in MySQL and cached on disk. Configuration subscription uses long‑polling with a 30‑second timeout for unchanged data.

The limitations of Config v1 are enumerated, including Redis‑based client request tracking latency, uncontrolled OpenAPI SDKs, broadcast‑based data sync leading to inconsistency after node failures, lack of multi‑active deployment, and missing configuration validation.

To address these issues, Paladin (Config v2) was developed. Key improvements include:

Configuration lifecycle management and simplification: Configurations are bound to groups rather than independent versions; changes are recorded only after publishing, reducing learning cost.

Isolation: Tenant, namespace, and group isolation prevent cross‑tenant impact.

Incremental publishing and reading: Version and configuration data are stored separately; only changed files are pushed, and clients use checksum comparison to decide updates.

Improved QPS and push latency: An LRU cache stores configuration content, while a HashMap‑based notification cache replaces Redis for faster broadcasts.

Strong consistency: Paladin adopts the Raft consensus algorithm to guarantee data consistency across cluster nodes.

High availability and multi‑active deployment: Separate Node, Portal, and Admin services, database‑centralized persistence, and anycast routing enable failover across data centers.

Client connection reuse: SDKs support multiplexed connections and provide agents or sidecars for languages without native SDKs.

Additional features: Platform space, keyspace configuration, format validation (XML, TOML, YAML, JSON, etc.), permission management, version control with rollback, colored releases, template configurations, import/export, and command‑line operational tools.

Performance testing on a 48‑core 2.8 GHz server shows that a single Paladin node can handle 30 万 configurations, serve up to 65 000 concurrent clients, and push updates within 40 ms on average. Listening to a single configuration by 10 000 clients completes within 600 ms.

The article concludes with a forward‑looking view: continued optimization of user experience, abstraction of feature/variable scenarios, integration with large‑model data distribution, and deeper coupling with container platforms (e.g., K8s) to replace etcd for higher performance. References to Raft papers and cloud‑native configuration center best practices are provided.