# Microservices: Configuration Management

* * *

In a **microservices architecture**, a **<mark class="bg-yellow-200 dark:bg-yellow-500/30">Config Server</mark>** <mark class="bg-yellow-200 dark:bg-yellow-500/30"> is a centralized place from where microservices obtain their configuration instead of keeping all configuration inside each service's code/deployment package</mark>.

Instead of:

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

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

you can have configuration managed centrally.

```plaintext
                    ┌──────────────────────┐
                    │     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:

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

redis:
  host: redis.example.com

logging:
  level: INFO
```

And `hotel-service` needs different configuration:

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

<mark class="bg-yellow-200 dark:bg-yellow-500/30">A Config Server exposes these configurations through an API</mark>. For example:

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

Response:

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

So, conceptually:

![](https://cdn.hashnode.com/uploads/covers/679f94da85491cdb2d8e2e57/7b62dac0-6c13-4b34-adec-5e253ad299c6.png align="center")

There are two ways a service can consume configuration.

> **1\. Startup configuration**

This is the simplest approach. The service retrieves its configuration during startup.

```plaintext
User Service starts
       │
       ▼
Fetch configuration
       │
       ▼
Start application
```

If configuration changes:

```plaintext
Change config
     ↓
Restart service
```

> **2\. Dynamic configuration**

More advanced systems allow:

```plaintext
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 **<mark class="bg-yellow-200 dark:bg-yellow-500/30">centralized configuration management</mark>**.

Suppose you have 20 microservices and each has:

```plaintext
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:

```plaintext
                 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 Parameter Store, Azure App Configuration

* * *

## 🚨 Risks & Challenges

*   **Single Point of Failure**: If the Config Server goes down, clients may fail to load configs.
    
*   **Latency**: Fetching configs at startup can slow service boot times.
    
*   **Security Concerns**: Misconfigured access can expose sensitive data.
    

* * *

## ⚠️ Configuration vs Secrets

**<mark class="bg-yellow-200 dark:bg-yellow-500/30">Don't treat your Config Server as a place to dump every secret.</mark>**

For example:

**Configuration**

```yaml
server:
  port: 5001

redis:
  host: redis.internal

logging:
  level: INFO

payment:
  timeout: 10
```

**Secrets**

```yaml
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:

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

* * *

Happy learning!