← Back to list

Dynamic Configuration in Spring Boot with Consul and Spring Cloud Config

In a distributed systems, keeping application configurations synchronized across microservices without downtime is essential. Hardcoded…

Rahul Kumar · 2025-08-02 10:15 · 0 claps · 2.8 min read paywalled
#spring-boot #spring-cloud #spring-cloud-config #consul #microservicesarchitecture
Open on Medium ↗
Wiki topics: 🏛️ · Architecture

Dynamic Configuration in Spring Boot with Consul and Spring Cloud Config

Dynamic Configuration in Spring Boot with Consul and Spring Cloud Config cover image

Dynamic Configuration in Spring Boot with Consul and Spring Cloud Config cover image

In a distributed systems, keeping application configurations synchronized across microservices without downtime is essential. Hardcoded properties or static application.yml files can cause service restarts, inconsistencies, and operational friction. This is where dynamic configuration using tools like HashiCorp Consul and Spring Cloud Config becomes powerful.

Why Dynamic Configuration?

  • Centralized management of configs across environments.
  • Real-time updates without restarting services.
  • Enables feature flags, throttling, or experimentation.
  • Secure, versioned, and auditable changes.

Dynamic configuration is not a new concept, many application earlier used to do it through backdoor channel, maybe an API which just change the value of a variable at run time, but everyone knew that it was problematic in a sense that there is a security and audit concern, also when it comes to microservices it gets more complex, how many API call we might need to call, how we will track it, what if it fails in some of the service etc.

Spring cloud config solved this problem by providing a(or few) service for just maintaining the config, it took the overload of run time changes to.

             ┌────────────────┐
             │ Config Source  │ (Git / Consul KV)
             └────────────────┘
                     │
        ┌─────────────────────────┐
        │ Spring Cloud Config Server │
        └─────────────────────────┘
                     │
    ┌────────────────┴────────────────┐
    │                                 │
┌────────────┐               ┌────────────┐
│ Microservice A│           │ Microservice B│
└────────────┘               └────────────┘
     ↑   ↓                           ↑   ↓
     Refresh Scope        Dynamic Property Access

Consul

Install Consul locally or use docker

docker run -d -p 8500:8500 --name=consul consul

Add Dependencies

In each Spring Boot service:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-consul-config</artifactId>
</dependency>

In bootstrap.yml

spring:
  application:
    name: pricing-service
  cloud:
    consul:
      host: localhost
      port: 8500
      config:
        format: YAML
        enabled: true
        default-context: application
        profile-separator: '::'

its self explanatory

Sample Consul KV Structure

Key: config/pricing-service/data

Value:

price.discount: 10
feature.toggle.new-ui: true

Spring Cloud automatically maps this to @Value or @ConfigurationProperties.

Dynamic Property Injection

@RefreshScope
@RestController
public class PriceController {

    @Value("${price.discount}")
    private int discount;

    @GetMapping("/discount")
    public String getDiscount() {
        return "Current discount: " + discount + "%";
    }
}

What does @RefreshScope do?

  • Normally, Spring beans are singleton and immutable after the application starts.
  • If you change a property in application.properties, the new value is not picked up until you restart the app.
  • With **@RefreshScope, the bean becomes refreshable**, meaning:
  • When you call **/actuator/refresh** endpoint (or trigger a refresh event), Spring re-creates the bean with the updated configuration from the external source.

How does it work internally?

  • @RefreshScope uses a proxy around the bean. (no surprises here)
  • On refresh, it destroys the old bean and creates a new instance with updated properties.
  • This works only if: Actuator is enabled (spring-boot-starter-actuator) management.endpoints.web.exposure.include=refresh (or *)

To refresh without restart:

curl -X POST http://localhost:8080/actuator/refresh

Real-Time Update Use Case

Imagine toggling a new feature rollout:

feature.toggle.recommendations: true
if (config.isRecommendationsEnabled()) {
    showRecommendations();
}

Change the flag in Consul → Refresh actuator → Behavior changes in real-time.

Benefits

Considerations

  • Always secure Consul (auth, TLS).
  • Don’t overuse refresh; prefer predictable releases. (A predictable system makes debugging easy not if, but when things go wrong)
  • Combine with feature flags carefully (e.g., FF4J, Togglz).

Consul : the swiss-army knife

Consul does a lot more than just being a key value store

Summary

Dynamic configuration with Spring Boot and Consul improves agility and operational confidence in managing microservice environments. Whether you’re toggling a feature or adjusting rates, the ability to make live changes without service restarts is a game-changer for modern DevOps and SRE teams.

This approach is ideal for:

  • Multi-environment configuration management.
  • Real-time feature flag management.
  • Reducing downtime for config changes.

메타데이터
post_id
7ae52fdd3243
slug
dynamic-configuration-in-spring-boot-with-consul-and-spring-cloud-config-7ae52fdd3243
url
https://medium.com/@27.rahul.k/dynamic-configuration-in-spring-boot-with-consul-and-spring-cloud-config-7ae52fdd3243
canonical_url
https://medium.com/@27.rahul.k/dynamic-configuration-in-spring-boot-with-consul-and-spring-cloud-config-7ae52fdd3243
author_url
https://medium.com/@27.rahul.k
status
ok
fetched_at
2026-07-18 14:18:03