Dynamic configuration updates in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Architecture

intermediate

Designing a dynamic configuration update system for microservices

You need to design a system that allows microservices to update their configuration dynamically without restarting. Which architectural component is essential to achieve this?

A A centralized configuration service that microservices poll periodically for updates.

B Embedding configuration files inside each microservice's container image.

C Hardcoding configuration values in the microservice source code.

D Using environment variables set only at microservice startup.

💡 Hint

Think about a component that can serve updated settings to many services without restarting them.

A centralized configuration service allows microservices to fetch updated configurations dynamically. Polling or push mechanisms enable updates without restarts. Embedding configs or hardcoding them prevents dynamic updates.

❓ scaling

intermediate

Scaling configuration updates in a large microservices environment

You have 1000 microservice instances needing configuration updates simultaneously. What is the best approach to efficiently propagate updates?

A Each instance polls the configuration service every second independently.

B Use a publish-subscribe system where the configuration service pushes updates to instances.

C Restart all microservices to reload configuration from local files.

D Manually update configuration on each instance via SSH.

💡 Hint

Consider a method that avoids thousands of independent requests at once.

A publish-subscribe system efficiently pushes updates to all instances simultaneously, reducing load and latency. Polling causes heavy load, restarts cause downtime, and manual updates are not scalable.

❓ tradeoff

advanced

Tradeoffs between push and pull models for configuration updates

Which statement best describes a tradeoff between push and pull models for dynamic configuration updates in microservices?

A Pull models guarantee immediate consistency; push models do not.

B Pull models reduce latency but require persistent connections; push models increase latency but simplify client design.

C Push models reduce latency but require persistent connections; pull models increase latency but simplify client design.

D Push models always use less network bandwidth than pull models regardless of scale.

💡 Hint

Think about how updates reach clients and the connection types involved.

Push models send updates immediately but need persistent connections like websockets. Pull models have clients ask periodically, increasing latency but simplifying client logic. Bandwidth and consistency depend on implementation.

❓ component

advanced

Key component for ensuring consistency of dynamic configuration across microservices

Which component is critical to ensure all microservices see a consistent configuration version during dynamic updates?

A A versioning system that tags configuration snapshots and enforces atomic updates.

B A load balancer that routes requests to updated microservices only.

C A logging system that records configuration changes asynchronously.

D A caching layer that stores old configuration indefinitely.

💡 Hint

Think about how to prevent microservices from using mixed or partial configurations.

Versioning and atomic updates ensure microservices switch to a new configuration simultaneously, avoiding inconsistency. Load balancers, caches, and logs do not guarantee configuration consistency.

❓ estimation

expert

Estimating capacity for configuration update propagation

You have 10,000 microservice instances. Each configuration update is 50 KB. Updates occur once every 10 minutes. Estimate the minimum network bandwidth needed to propagate updates to all instances within 1 minute.

A Approximately 50 Mbps

B Approximately 67 Mbps

C Approximately 100 Mbps

D Approximately 83 Mbps

💡 Hint

Calculate total data size and divide by propagation time, then convert to Mbps.

Total data = 10,000 instances * 50 KB = 500,000 KB = 500 MB. To send in 1 minute (60 seconds): 500 MB / 60 s ≈ 8.33 MB/s. Convert to Mbps: 8.33 MB/s * 8 = 66.64 Mbps. Considering overhead and safety margin, ~83 Mbps is reasonable.