Problem Without Centralized Configuration

In microservices:
-
Each service has its own
application.properties -
Environment changes (dev/qa/prod) require redeployment
-
Configuration drift occurs
-
Security risk (secrets in code)
πΉ What is Spring Cloud Config?
Spring Cloud Config provides externalized, centralized configuration for all microservices.
It uses a Config Server that fetches configuration from:
-
Git (most common)
-
File system
-
Vault
πΉ Architecture
Client Service
β¬
Config Server
β¬
Git Repository
Each microservice fetches config at startup or runtime.
πΉ How It Works (Flow)
-
Config Server starts
-
Reads configuration from Git repo
-
Microservice starts
-
Microservice fetches config from Config Server
-
Config is applied based on:
-
application name
-
profile (dev/prod)
-
πΉ Example Structure (Git)
πΉ Example Client Configuration
πΉ Refreshing Config Without Restart
Use:
-
@RefreshScope -
Actuator
/refreshendpoint
πΉ Advantages
β
Centralized config
β
Environment-based config
β
No redeployment for config change
β
Secure secrets management
β
Consistency across services
πΉ Disadvantages
β Additional infrastructure
β Config Server becomes critical dependency
β Needs HA setup
πΉ Real-World Example
π³ Change DB password in Git
β Refresh Config
β All services updated without restart
β Interview One-Liner
βSpring Cloud Config externalizes configuration and allows centralized, environment-specific, and dynamic configuration management.β
πΉ Follow-Up Questions Interviewers Ask
-
How do you secure Config Server?
-
Difference between Spring Cloud Config & Kubernetes ConfigMaps?
-
How does @RefreshScope work internally?