Config server pattern in Microservices - System Design Guide

Problem Statement

When multiple microservices each manage their own configuration files, updating settings becomes error-prone and inconsistent. This leads to configuration drift, deployment delays, and difficulty in managing environment-specific settings across services.

Solution

A centralized configuration server stores all configuration data for microservices in one place. Services fetch their configuration from this server at startup or runtime, ensuring consistent and dynamic configuration management across environments.

Architecture

Configuration

→Microservice A

↓

→Microservice B

↓

Microservice C

Microservice C

This diagram shows a centralized configuration server providing configuration data to multiple microservices, ensuring consistent settings across all services.

Trade-offs

✓ Pros

→

Centralizes configuration management, reducing duplication and errors.

→

Enables dynamic configuration updates without redeploying services.

→

Simplifies environment-specific configuration handling.

→

Improves consistency and auditability of configuration changes.

✗ Cons

→

Introduces a single point of failure if the config server is down.

→

Adds network latency for configuration retrieval at startup or runtime.

→

Requires secure access control to protect sensitive configuration data.

Use when managing multiple microservices with shared or environment-specific configurations, especially when configuration changes are frequent or need to be dynamic.

Avoid when the system has only a few services with static configurations or when introducing a config server adds unnecessary complexity for small-scale deployments.

Real World Examples

Netflix

Uses a centralized config server to manage configurations for hundreds of microservices, enabling dynamic updates and consistent environment settings.

Spotify

Employs a config server pattern to handle feature flags and environment-specific settings across their microservices, allowing rapid experimentation and rollout.

Amazon

Uses centralized configuration management to maintain consistent service behavior across multiple regions and deployment environments.

Code Example

The before code shows a microservice loading configuration from a local file, which can lead to inconsistencies. The after code fetches configuration from a centralized config server via HTTP, ensuring all services use the same settings.

Microservices

### Before: Each microservice loads config from local file
import json
class Service:
    def __init__(self):
        with open('config.json') as f:
            self.config = json.load(f)

### After: Microservice fetches config from centralized config server
import requests
class Service:
    def __init__(self):
        response = requests.get('http://config-server/config/service')
        self.config = response.json()

Alternatives

Environment Variables

Stores configuration locally in environment variables per service instead of a centralized server.

Use when: Use when services are few and configuration changes are rare or managed manually.

Service Mesh Configuration

Manages some configuration aspects at the network proxy layer rather than in application config files.

Use when: Choose when configuration relates mainly to networking and security policies.

Distributed Configuration Store

Uses distributed key-value stores like Consul or Etcd for configuration instead of a dedicated config server.

Use when: Use when high availability and distributed consensus for configuration are critical.

Summary

Centralized config servers prevent inconsistent and error-prone configuration management in microservices.

They enable dynamic updates and environment-specific settings from a single source of truth.

Config servers add complexity and require high availability but improve consistency at scale.