Microservices: Configuration Management

In a microservices architecture, a Config Server is a centralized place from where microservices obtain their configuration instead of keeping all configuration inside each service's code/deployment package.

Instead of:

user-service/
    config.py
    .env
    application.yml

hotel-service/
    config.py
    .env
    application.yml

you can have configuration managed centrally.

                    ┌──────────────────────┐
                    │     Config Server    │
                    │                      │
                    │ user-service.yml     │
                    │ hotel-service.yml    │
                    │ rating-service.yml   │
                    │ common.yml           │
                    └──────────┬───────────┘
                               │
              ┌────────────────┼────────────────┐
              │                │                │
              ▼                ▼                ▼
       User Service     Hotel Service    Rating Service
         :5001             :5002            :5003

What exactly does a Config Server do?

Imagine your user-service needs:

database:
  host: mysql.example.com
  port: 3306
  name: users

redis:
  host: redis.example.com

logging:
  level: INFO

And hotel-service needs different configuration:

database:
  host: mysql.example.com
  port: 3306
  name: hotels

A Config Server exposes these configurations through an API. For example:

GET http://config-server:8888/user-service

Response:

{
  "database.host": "mysql.example.com",
  "database.port": 3306,
  "database.name": "users",
  "logging.level": "INFO"
}

The service retrieves its configuration during startup.

So, conceptually:

There are two ways a service can consume configuration.

1. Startup configuration

User Service starts
       │
       ▼
Fetch configuration
       │
       ▼
Start application

If configuration changes:

Change config
     ↓
Restart service

This is the simplest approach.

2. Dynamic configuration

More advanced systems allow:

Config changes
      │
      ▼
Config Server
      │
      ▼
Running microservice
      │
      ▼
Configuration updated

without restarting the service. This approach introduces additional complexity around refresh, consistency, validation, and rollback.

Why do we need Config Server?

The biggest reason is centralized configuration management.

Suppose you have 20 microservices and each has:

DB_HOST
DB_PORT
REDIS_HOST
KAFKA_HOST
LOG_LEVEL
JWT_EXPIRATION
...

Managing these independently at the application/deployment level can become painful.

With centralized configuration:

                 Config Server
                      │
       ┌──────────────┼──────────────┐
       │              │              │
       ▼              ▼              ▼
    User           Hotel          Rating
   Service         Service        Service

You can manage:

• database configuration

• Redis configuration

• Kafka configuration

• logging levels

• feature flags

• external API URLs

• timeout values

• application-specific settings

• environment-specific settings

from a central location.

Different ways to implement a Config Server

There isn't just one approach. I'd categorize the options into two major approaches.

Approach 1: Dedicated Config Server

Examples: - Consul KV, Spring Cloud Config, etcd, etc.

Approach 2: Cloud Providers

Examples: - AWS Systems Manager Parameter Store

⚠️ Configuration vs Secrets

Don't treat your Config Server as a place to dump every secret.

For example:

Configuration

server:
  port: 5001

redis:
  host: redis.internal

logging:
  level: INFO

payment:
  timeout: 10

Secrets

database:
  password: SuperSecretPassword123

This should generally not be sitting in a normal Git configuration repository. Instead use something like: AWS Secrets Manager, HashiCorp Vault, Kubernetes Secrets, etc.

Then your application can have:

             Application
              /        \
             /          \
            ▼            ▼
     Config Server    Secret Manager
          │                 │
          ▼                 ▼
       settings          passwords
       timeouts          API keys
       URLs              credentials
       flags             tokens

Happy learning!