Dynamic configuration updates in Microservices - Architecture Diagram

System Overview - Dynamic configuration updates

This system enables microservices to receive configuration changes dynamically without restarting. It ensures services always use the latest settings for features, limits, or behavior, improving flexibility and uptime.

Architecture Diagram

User
  |
  v
+----------------+
| Load Balancer  |
+----------------+
        |
        v
+----------------+       +-------------------+
| API Gateway    |<----->| Configuration     |
+----------------+       | Management Service|
        |                +-------------------+
        v                        |
+----------------+              v
| Microservice A |<------------+ Cache (Config)   |
+----------------+              |
        |                       v
+----------------+       +-------------------+
| Microservice B |<----->| Configuration DB  |
+----------------+       +-------------------+

Components

Load Balancer

load_balancer

Distributes incoming requests evenly to API Gateway instances

API Gateway

api_gateway

Routes client requests to microservices and handles authentication

Configuration Management Service

service

Manages configuration updates and pushes changes to cache and services

Cache (Config)

cache

Stores latest configuration for fast access by microservices

Configuration DB

database

Persists configuration data reliably for recovery and audit

Microservice A

service

Consumes configuration from cache to adjust behavior dynamically

Microservice B

service

Consumes configuration from cache to adjust behavior dynamically

Request Flow - 8 Hops

User → Load Balancer

Load Balancer → API Gateway

API Gateway → Microservice A

Microservice A → Cache (Config)

Configuration Management Service → Configuration DB

Configuration Management Service → Cache (Config)

Configuration Management Service → Microservice A

Microservice A → Microservice A

Failure Scenario

Component Fails:Cache (Config)

Impact:Microservices experience slower config fetches as they fallback to Configuration DB; possible increased latency

Mitigation:Microservices retry cache and fallback to DB; Configuration Management Service rebuilds cache from DB; add cache replication for high availability

Architecture Quiz - 3 Questions

Which component ensures microservices get configuration updates without restarting?

A API Gateway

B Load Balancer

C Configuration Management Service

D Configuration DB

Design Principle

This architecture uses a centralized configuration management service with caching and push notifications to enable microservices to update their settings dynamically without downtime, improving system flexibility and responsiveness.

Practice

1. What is the main benefit of using dynamic configuration updates in microservices?

easy

A. Encrypt all service communication by default

B. Change service settings without restarting or downtime

C. Reduce the size of service containers

D. Increase the number of microservices automatically

Solution

1. Step 1: Understand dynamic configuration updates

   Dynamic configuration updates allow changing settings while the service is running.

2. Step 2: Identify the main benefit

   This avoids restarting services, preventing downtime and improving flexibility.

3. Final Answer:

   Change service settings without restarting or downtime -> Option B

4. Quick Check:

   Dynamic config = no downtime updates [OK]

Hint: Dynamic config means no restart needed for changes [OK]

Common Mistakes:

• Confusing dynamic config with scaling services
• Thinking it reduces container size
• Assuming it encrypts communication automatically

2. Which of the following is a common method for microservices to receive dynamic configuration updates?

easy

A. Polling a central configuration server periodically

B. Hardcoding config values in source code

C. Restarting the service every hour

D. Using static environment variables only

Solution

1. Step 1: Review methods for dynamic config updates

   Common methods include polling or push from a central config server.

2. Step 2: Identify the correct method

   Polling a config server lets services fetch updates regularly without restart.

3. Final Answer:

   Polling a central configuration server periodically -> Option A

4. Quick Check:

   Polling config server = dynamic updates [OK]

Hint: Dynamic config needs active update fetching, not static values [OK]

Common Mistakes:

• Thinking hardcoded values can update dynamically
• Assuming restart is needed for updates
• Believing static env vars update automatically

3. Consider this pseudocode for a microservice fetching config updates:

config = load_config()
while True:
    if config_server.has_update():
        config = config_server.get_update()
    sleep(10)
    print(config['feature_flag'])

What will this code do when the feature_flag changes on the config server?

medium

A. Print the old feature_flag value forever

B. Crash because config_server.has_update() is undefined

C. Print nothing because of missing initial config

D. Update and print the new feature_flag value every 10 seconds

Solution

1. Step 1: Analyze the update check loop

   The code checks if the config server has an update, then fetches it.

2. Step 2: Understand the print behavior

   Every 10 seconds it prints the current feature_flag from the updated config.

3. Final Answer:

   Update and print the new feature_flag value every 10 seconds -> Option D

4. Quick Check:

   Polling loop updates config = prints new value [OK]

Hint: Polling loop updates config then prints latest value [OK]

Common Mistakes:

• Assuming config never updates after initial load
• Thinking code crashes due to undefined methods (assumed defined)
• Ignoring the sleep and print inside the loop

4. A microservice uses a push-based config update system but sometimes misses updates. What is a likely cause?

medium

A. The service does not acknowledge receipt of updates

B. The service polls the config server too frequently

C. The service restarts after every update

D. The config server uses static environment variables

Solution

1. Step 1: Understand push-based config update mechanism

   Push systems send updates and expect acknowledgments to confirm delivery.

2. Step 2: Identify why updates are missed

   If the service does not acknowledge, the server may not resend or confirm updates.

3. Final Answer:

   The service does not acknowledge receipt of updates -> Option A

4. Quick Check:

   Missing ack = missed updates in push system [OK]

Hint: Push updates need acknowledgments to avoid missing data [OK]

Common Mistakes:

• Confusing push with polling frequency issues
• Assuming restarts cause missed updates
• Thinking static env vars relate to push update failures

5. You design a microservices system with dynamic config updates using a central config server. To ensure minimal latency and high availability, which approach is best?

hard

A. Embed config in each service and restart services on config change

B. Use a single config server with clients polling every second

C. Deploy multiple config server replicas with push notifications and local caching

D. Use static config files updated manually on each service host

Solution

1. Step 1: Consider latency and availability needs

   Multiple replicas reduce single points of failure and improve response times.

2. Step 2: Evaluate update delivery methods

   Push notifications with local caching reduce latency and avoid constant polling.

3. Final Answer:

   Deploy multiple config server replicas with push notifications and local caching -> Option C

4. Quick Check:

   Replicas + push + cache = low latency & high availability [OK]

Hint: Replicas + push + cache = best for latency and availability [OK]

Common Mistakes:

• Relying on single server causes downtime
• Polling every second wastes resources
• Restarting services causes downtime
• Manual static updates are error-prone and slow