intermediate~2.5h

Centralized Configuration: Config Server & Config Client

Ten services each with their own application.properties means changing one shared value ten separate times. This module is the single source of truth that replaces that.

Learning objectives

Beginner: Stand up a Config Server serving properties from a Git repository.
Intermediate: Point a Config Client service at the Config Server and consume centralized properties.
Advanced: Use @RefreshScope and the Config Bus to push a configuration change to every running instance without redeploying.

◆ The problem

A payment-gateway URL used by six different services means six separate application.properties files to update, in six separate deployments, whenever that URL changes — miss one and you have six services running six different configurations of the truth.

Spring Cloud Config Server centralizes this: one service reads configuration files (typically from a Git repository, so every config change is version-controlled) and serves them over HTTP to every other service that asks.

# config-server's application.yml
spring:
  cloud:
    config:
      server:
        git:
          uri: https://github.com/yourorg/config-repo

A downstream service (say, order-service) doesn't read its OWN application.properties for shared values anymore — it asks the Config Server for them at startup.

# order-service's application.yml
spring:
  application:
    name: order-service
  config:
    import: "configserver:http://localhost:8888"

The Config Server looks up a file named order-service.yml (or order-service-prod.yml for the prod profile) in its Git repo — matching by application name, exactly like Spring Boot's own profile-file-naming convention from the Spring Boot category, just centralized instead of local.

⚠ Common real-world trap

Config Server only serves NEW values to a service on its NEXT startup by default — changing a value in the Git repo does nothing to already-running instances, which is a common source of "I changed it, why didn't anything happen" confusion.

@RefreshScope on a bean makes it eligible to be recreated on demand, picking up fresh config values, when a refresh is triggered — without restarting the whole service.

@RefreshScope
@RestController
public class FeatureFlagController {
    @Value("${feature.new-checkout.enabled}")
    private boolean newCheckoutEnabled;
}

Calling /actuator/refresh manually on every single instance of every service, one at a time, doesn't scale past a handful of services. Spring Cloud Bus connects every service instance to a shared message broker (typically Kafka — the exact broker covered in the Kafka & Microservices category) so ONE refresh trigger fans out to every connected instance automatically.

✓ Quick recap

Config Server centralizes properties in one Git-backed service instead of scattering them across every service's own files.
Config Client services import config at startup, matched by application name — the same profile-naming convention as local Spring Boot config.
@RefreshScope beans can pick up new values without a redeploy, but only when a refresh is explicitly triggered.
Config Bus fans a single refresh trigger out to every connected instance via a shared message broker, instead of refreshing instances one at a time.

Want a visual for this concept?

Generate a diagram tailored to “Centralized Configuration: Config Server & Config Client” — the AI picks whichever visual (flowchart, comparison, sequence, etc.) best fits.

Practice quiz

Next Step

Continue to Service Discovery: Eureka & Client-Side Load Balancing →← Back to all Spring Cloud chapters