Config server pattern in Microservices - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is the Config Server Pattern in microservices?

It is a design pattern where a central server stores configuration settings for multiple microservices, allowing them to fetch their configs dynamically at runtime.

beginner

Why use a Config Server instead of local config files?

A Config Server centralizes configuration, making it easier to update settings for many services without redeploying them individually.

intermediate

How does a microservice typically get its configuration from a Config Server?

The microservice calls the Config Server API during startup or refresh to retrieve its configuration data, often using service name and profile as keys.

intermediate

What is a common storage backend for Config Servers?

Config Servers often use Git repositories or centralized databases to store configuration files securely and version-controlled.

advanced

Name one challenge when using Config Server Pattern and how to address it.

Challenge: Config Server downtime can affect microservices startup. Solution: Use caching and fallback configs locally to handle temporary unavailability.

What is the main role of a Config Server in microservices?

A Store and serve configuration centrally

B Manage service discovery

C Handle user authentication

D Balance network traffic

The Config Server stores configuration centrally and serves it to microservices.

Which storage is commonly used by Config Servers to keep config files?

A Git repository

B Local service disk only

C User browser cache

D Load balancer

Git repositories are commonly used for version-controlled config storage.

How do microservices usually fetch their configuration from a Config Server?

A By sending email requests

B By polling a database every second

C By reading local environment variables only

D By calling Config Server API at startup

Microservices call the Config Server API during startup or refresh to get configs.

What is a key benefit of using a Config Server Pattern?

A Faster database queries

B Centralized config management

C Improved UI design

D Automatic code compilation

Centralized config management simplifies updates and consistency.

What should microservices do if the Config Server is temporarily unavailable?

A Crash immediately

B Wait indefinitely

C Use cached or fallback configs

D Restart the Config Server

Using cached or fallback configs helps maintain service availability.

Explain the Config Server Pattern and its benefits in microservices architecture.

Think about how multiple services get their settings from one place.

Describe a typical request flow when a microservice fetches configuration from a Config Server.

Imagine how a service asks for its settings when it starts.

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