Why Spring Cloud Config Falls Short and How We Rebuilt It with Long Polling

Introduction

Traditional monolithic architectures are evolving toward micro‑services, making configuration management increasingly complex. A configuration center centralizes configuration data stored in various media such as files (Git, SVN), relational databases (MySQL, Oracle), NoSQL stores (Redis, MongoDB), or third‑party middleware (Zookeeper).

Spring Cloud Config is the typical choice for Spring Boot projects, but it has notable drawbacks that prompted us to redesign its refresh mechanism.

Problems with Spring Cloud Config (Git Backend)

Permission Control Issues

Git permissions control push/delete rights at the repository level, not per‑directory or per‑file, leading to situations where teams can view each other's configurations unintentionally.

Different teams can see each other's configuration!

Granularity Problems

Storing configurations in Git means any change affects the whole file, making fine‑grained updates and gray‑release difficult.

Using a database as the storage medium offers two advantages:

Developing a configuration management system on a database is simpler than on Git.

Each configuration maps to a single database record, providing fine‑grained control for selective updates and gray releases.

Spring Cloud Config supports a JDBC backend; enabling it requires setting: spring.profiles.active=jdbc However, we discovered a larger issue with the refresh mechanism.

Refresh Mechanism Shortcomings

Spring Cloud Config relies on Webhook callbacks and Spring Cloud Bus to push updates, which depends on external version‑control services and message queues, introducing latency and additional points of failure.

Spring Cloud Config's refresh mechanism is a pitfall!

When configurations reside in a database, there is no native webhook support, and the message‑bus‑based refresh adds complexity and potential downtime.

Long Polling as a Solution

What Is Long Polling?

Unlike short polling, where the client repeatedly requests the server for updates, long polling keeps the HTTP request open until a change occurs or a timeout expires, reducing unnecessary traffic.

Implementation with DeferredResult

We used Spring's DeferredResult to implement long polling. After Servlet 3.0 introduced asynchronous request handling, DeferredResult allows the request thread to be released while the server waits for configuration changes.

Typical flow:

Client establishes a TCP connection and sends an HTTP request.

Server monitors configuration changes for up to 60 seconds.

If no change, the server returns a 304 status; the client re‑issues the request.

If a change occurs, the server calls DeferredResult.setResult, returns a 200 response, and the client fetches the updated configuration.

To detect database changes, we employed MySQL's mysql‑udf‑http functions together with triggers, allowing the database to actively notify the configuration service when a row changes.

Performance Considerations

Long polling maintains an open connection per client. In our tests, an 8 GB, 4‑core VM could handle roughly 8,000 concurrent connections without issue.

Conclusion

By replacing Spring Cloud Config's default Git‑based refresh with a database‑backed, long‑polling mechanism using DeferredResult, we achieved finer configuration granularity, better permission control, and more reliable real‑time updates suitable for our micro‑service environment.