Config server pattern in Microservices - Scalability & System Analysis

Scalability Analysis - Config server pattern

Growth Table: Config Server Pattern Scaling

Users / Services	100 Users / 10 Services	10K Users / 100 Services	1M Users / 1000 Services	100M Users / 10,000 Services
Config Requests per Second	~50-100	~5,000	~50,000	~500,000
Config Server Instances	1-2	3-5 (load balanced)	10-20 (clustered)	50+ (sharded clusters)
Config Data Size	Small (KBs)	Medium (MBs)	Large (100s MBs)	Very Large (GBs)
Cache Usage	Basic in-memory cache	Distributed cache (Redis)	Multi-level cache + CDN	Global CDN + edge caches
Network Bandwidth	Low	Moderate	High	Very High

First Bottleneck

The first bottleneck is the config server itself. As the number of microservices and users grow, the config server faces high read traffic for configuration data. Without caching, the server CPU and memory get overwhelmed. Also, the underlying storage (e.g., Git repo or database) can become slow under heavy load.

Scaling Solutions

• Horizontal scaling: Add more config server instances behind a load balancer to distribute requests.
• Caching: Use in-memory caches on config servers and distributed caches like Redis to reduce backend hits.
• Sharding: Partition config data by service groups or environments to reduce single server load.
• CDN / Edge caching: For static config files, use CDN to serve configs closer to services.
• Asynchronous updates: Push config changes to services instead of frequent polling to reduce request volume.
• Optimize storage: Use fast storage like SSDs or in-memory databases for config data.

Back-of-Envelope Cost Analysis

Assuming 1000 microservices each polling config every 30 seconds:

• Requests per second = 1000 services * (1/30) = ~33 QPS
• At 1M users with 1000 services, QPS can reach 50,000+ due to retries and bursts.
• Config data size per request ~10 KB -> Bandwidth = 50,000 * 10 KB = ~500 MB/s (~4 Gbps)
• Storage needs depend on config versions; typically a few GBs but grows with history.
• CPU and memory on config servers must handle peak QPS with caching to avoid overload.

Interview Tip

Start by explaining the config server role and typical traffic patterns. Identify the bottleneck as the config server under read load. Discuss caching and horizontal scaling first. Then mention sharding and CDN for large scale. Always connect solutions to the bottleneck you identified. Use simple analogies like a library lending books (config data) to many readers (services).

Self Check

Question: Your config server handles 1000 QPS. Traffic grows 10x. What do you do first and why?

Answer: Add caching to reduce backend load and horizontally scale config server instances behind a load balancer. This reduces CPU/memory bottleneck and spreads traffic.

Key Result

The config server pattern scales well initially but the config server becomes the first bottleneck under high read traffic. Caching and horizontal scaling are key first steps to handle growth.

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