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.

Practice

1. What is the main purpose of the Config Server Pattern in microservices architecture?

easy

A. To manage database connections for microservices

B. To centralize configuration management for multiple microservices

C. To handle user authentication and authorization

D. To balance load between microservices

Solution

1. Step 1: Understand the role of configuration in microservices

   Each microservice needs configuration settings like URLs, credentials, and feature flags.

2. Step 2: Identify what the Config Server Pattern provides

   The pattern centralizes these settings in one place, so all microservices can fetch consistent configs.

3. Final Answer:

   To centralize configuration management for multiple microservices -> Option B

4. Quick Check:

   Config Server Pattern = Centralized config [OK]

Hint: Config Server centralizes configs, not user or load tasks [OK]

Common Mistakes:

• Confusing config management with authentication
• Thinking it manages database connections
• Assuming it balances load

2. Which of the following is the correct way for a microservice to fetch configuration from a Config Server?

easy

A. Microservice sends HTTP requests to Config Server to get configs

B. Microservice reads local config files only

C. Microservice uses database queries to fetch configs

D. Microservice uses message queues to receive configs

Solution

1. Step 1: Identify communication method with Config Server

   Config Server usually exposes REST APIs for microservices to request configs.

2. Step 2: Match options with typical Config Server usage

   HTTP requests are the standard way; local files, DB queries, or message queues are not typical for config fetching.

3. Final Answer:

   Microservice sends HTTP requests to Config Server to get configs -> Option A

4. Quick Check:

   Config Server uses HTTP requests [OK]

Hint: Config Server serves configs via HTTP, not local files or DB [OK]

Common Mistakes:

• Assuming configs come from local files only
• Thinking configs are fetched via database queries
• Confusing message queues with config delivery

3. Consider this simplified flow:
1. Microservice starts
2. Requests config from Config Server
3. Config Server returns config
4. Microservice uses config to connect to DB
What happens if the Config Server is down when the microservice starts?

medium

A. Microservice connects to DB without any config

B. Microservice automatically generates default config and continues

C. Microservice uses cached config or fails to start if none available

D. Microservice waits indefinitely for Config Server to respond

Solution

1. Step 1: Understand Config Server availability impact

   If Config Server is down, microservice cannot fetch fresh config at startup.

2. Step 2: Consider typical microservice behavior

   Most microservices cache last known config or fail to start if no config is available.

3. Final Answer:

   Microservice uses cached config or fails to start if none available -> Option C

4. Quick Check:

   Config Server down = use cache or fail [OK]

Hint: Microservices rely on cached config if Config Server is unreachable [OK]

Common Mistakes:

• Assuming microservice generates default config automatically
• Thinking microservice connects without config
• Believing microservice waits forever

4. A developer notices that after updating configuration in the Config Server, microservices do not reflect changes immediately. What is the most likely cause?

medium

A. Microservices cache old config and need refresh or restart

B. Config Server failed to save the new config

C. Microservices do not support external config fetching

D. Network issues prevent microservices from reaching Config Server

Solution

1. Step 1: Analyze why config changes are not reflected

   Microservices often cache configs to avoid frequent calls to Config Server.

2. Step 2: Identify common cause for stale configs

   Without refresh or restart, microservices keep using cached old configs.

3. Final Answer:

   Microservices cache old config and need refresh or restart -> Option A

4. Quick Check:

   Config changes need refresh to apply [OK]

Hint: Config changes require microservice refresh to apply [OK]

Common Mistakes:

• Assuming Config Server did not save changes
• Thinking microservices ignore external configs
• Blaming network without checking cache

5. You are designing a Config Server for a large microservices system with hundreds of services. Which approach best ensures scalability and security?

hard

A. Embed configs inside each microservice and update by redeploying services

B. Use a single database table for all configs without encryption

C. Store configs in a public Git repository without access control

D. Use a centralized Config Server with versioned configs, secure access, and caching at clients

Solution

1. Step 1: Consider scalability needs

   Centralized Config Server with versioning and caching reduces load and supports many services efficiently.

2. Step 2: Consider security best practices

   Secure access and encryption protect sensitive configs; public repos or unencrypted DB tables are unsafe.

3. Final Answer:

   Use a centralized Config Server with versioned configs, secure access, and caching at clients -> Option D

4. Quick Check:

   Scalable & secure config = centralized + versioning + security [OK]

Hint: Centralize configs with security and caching for scale [OK]

Common Mistakes:

• Embedding configs in services causes redeploy overhead
• Using public repos exposes sensitive data
• Storing unencrypted configs risks security breaches