Designing a Configuration Center: Key Considerations and Architecture

Preface

A reader asked whether a comprehensive article on configuration centers could be written, especially after being asked in an interview how to design one, so this piece presents the essential considerations.

Is It Necessary to Reinvent the Wheel?

When interviewers ask you to design a configuration center, you can first mention existing open‑source solutions and question the need to build from scratch, but if the requirement is to create a custom solution, you should outline your design ideas.

Configuration Storage Selection

The storage layer is fundamental; most open‑source centers use MySQL, though MongoDB or other databases are also viable. MySQL may require more tables with joins, while MongoDB can simplify the schema with embedded documents.

Beyond basic configuration data, auxiliary tables for users and permissions are needed, and considerations for high availability such as MySQL master‑slave or MongoDB’s native distribution are discussed.

Local caching on the client side is recommended to provide service continuity when the database is unavailable, as seen in Apollo and Nacos.

Configuration Isolation

Isolation across environments (dev, test, prod) is essential; traditionally this is done with separate config files, but a center can manage it centrally.

Isolation can also be achieved via namespaces, ensuring that different groups cannot access each other's configurations.

Three isolation approaches are described: adding an environment field in shared storage, deploying separate centers per environment, and a hybrid model where a single management UI controls multiple environment‑specific instances (e.g., Apollo).

Configuration Push Refresh

Real‑time push of configuration changes to applications is critical for user experience. Traditional pull‑based polling (e.g., every minute) introduces latency, while push mechanisms using techniques like Spring’s DeferredResult provide immediate updates.

A combined push‑pull strategy is recommended to ensure timeliness and eventual consistency while reducing server load.

Integrating Spring

Spring is the de‑facto framework for Java microservices; configuration values are typically accessed via @Value or @ConfigurationProperties. To source these values from a configuration center, the center must load properties into Spring’s ConfigurableEnvironment and expose them as PropertySource objects.

Permission Auditing

Regardless of whether a single or multiple centers are deployed, robust permission control is required to prevent unauthorized changes, with clear responsibilities for who can modify configurations.

Metrics Monitoring

As middleware, a configuration center should expose performance metrics. Approaches include exposing metrics for pull‑based systems like Prometheus, pushing metrics to monitoring platforms (e.g., Apollo’s integration with Cat), or providing a SPI for custom tracer integrations.

Open API / Multi‑Language SDK

Most popular centers provide Java SDKs, but for polyglot environments, open APIs enable developers to build SDKs in other languages, ensuring broader adoption.

About the Author

Yin Jihuan, a technology enthusiast and author of several Spring Cloud books, invites readers to obtain curated learning materials on Spring Cloud, Alibaba, Sharding‑JDBC, XXL‑JOB, MongoDB, web crawling, and more via the “Yuan Tiandi” public account.