Why Config server pattern in Microservices? - Purpose & Use Cases

The Big Idea

What if you could change settings for all your apps with one simple update, no restarts needed?

The Scenario

Imagine you have many small apps (microservices) running, each needing settings like database info or feature flags. You write these settings inside each app separately.

When you want to change a setting, you must update every app one by one and restart them. This is like changing the recipe in every kitchen instead of having one master recipe book.

The Problem

Updating settings manually is slow and risky. You might forget one app or make a typo. Restarting many apps causes downtime and confusion.

It's hard to keep track of which app has which version of settings. This leads to bugs and unhappy users.

The Solution

The Config server pattern solves this by having one central place to store all settings. Apps ask this server for their settings when they start or even while running.

This means you change settings once, and all apps get the update automatically or on restart. It's like having one recipe book that all kitchens use.

Before vs After

✗ Before

serviceA_config = { 'db': 'localhost', 'featureX': False }
serviceB_config = { 'db': 'localhost', 'featureX': False }

✓ After

config_server = { 'serviceA': { 'db': 'localhost', 'featureX': False }, 'serviceB': { 'db': 'localhost', 'featureX': False } }
serviceA_config = fetch_from_config_server('serviceA')
serviceB_config = fetch_from_config_server('serviceB')

What It Enables

It enables easy, safe, and consistent configuration management across many services without manual errors or downtime.

Real Life Example

Think of a large online store with dozens of microservices. When they want to turn on a sale feature, they update the config server once, and all services instantly know about the sale without restarts or mistakes.

Key Takeaways

Manual config updates are slow and error-prone.

Config server centralizes settings for all services.

It makes updates fast, safe, and consistent.

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