Config server pattern in Microservices - System Design Exercise

Design: Centralized Configuration Server for Microservices

Design focuses on the centralized config server and its interaction with microservices. Out of scope are the internal implementation details of each microservice and their business logic.

Functional Requirements

FR1: Provide a central place to store configuration for multiple microservices

FR2: Allow microservices to fetch their configuration at startup and refresh at runtime

FR3: Support versioning and environment-specific configurations (e.g., dev, staging, production)

FR4: Ensure secure access to configuration data

FR5: Handle high availability and low latency for configuration requests

FR6: Support rollback to previous configuration versions if needed

Non-Functional Requirements

NFR1: Must support at least 100 microservices fetching configs concurrently

NFR2: API response latency for config fetch should be under 100ms p99

NFR3: System availability target: 99.9% uptime

NFR4: Configuration data size per service should be under 1MB

NFR5: Support secure communication (e.g., TLS) and authentication

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

Configuration storage (database or file system)

REST or gRPC API for config retrieval

Authentication and authorization module

Cache layer for fast config access

Version control for configuration data

Notification or webhook system for config changes

Design Patterns

Centralized configuration management

Cache aside pattern for config caching

Publish-subscribe for config change notifications

Circuit breaker for config server failures

Immutable configuration versions

Reference Architecture

                    +---------------------+
                    |  Configuration Store |
                    |  (e.g., Git, DB)     |
                    +----------+----------+
                               |
                               v
+----------------+       +---------------------+       +----------------+
| Microservice 1 | <---> | Config Server (API) | <---> | Auth Service   |
+----------------+       +---------------------+       +----------------+
         ^                          |
         |                          v
+----------------+          +--------------+
| Microservice 2 |          | Cache Layer  |
+----------------+          +--------------+

Legend:
- Microservices fetch config from Config Server API
- Config Server reads from Configuration Store and caches data
- Auth Service handles secure access
- Cache Layer reduces latency and load on store

Components

Configuration Store

Git repository or relational database (e.g., PostgreSQL)

Stores all configuration files and versions securely

Config Server API

RESTful API or gRPC service

Serves configuration data to microservices on request

Cache Layer

In-memory cache like Redis or local memory cache

Speeds up config retrieval and reduces load on the store

Authentication Service

OAuth2 or JWT based auth system

Ensures only authorized microservices can access configs

Notification System

Message queue or webhook system

Notifies microservices of config changes for refresh

Request Flow

1. 1. Microservice starts and requests its configuration from Config Server API.

2. 2. Config Server checks cache for requested config.

3. 3. If cache miss, Config Server fetches config from Configuration Store.

4. 4. Config Server returns config data to microservice securely after authentication.

5. 5. Microservice uses config and optionally subscribes for change notifications.

6. 6. When config changes, Notification System alerts subscribed microservices.

7. 7. Microservices refresh their config by repeating steps 1-4.

Database Schema

Entities: - ConfigurationFile: id, service_name, environment, version, content, created_at - Service: id, name, authentication_credentials - ConfigVersionHistory: id, configuration_file_id, version, change_description, created_at Relationships: - One Service has many ConfigurationFiles (one per environment/version) - ConfigurationFile has many ConfigVersionHistory entries for version tracking

Scaling Discussion

Bottlenecks

High read load on Configuration Store causing latency

Cache invalidation delays leading to stale configs

Authentication service becoming a bottleneck under load

Network latency between microservices and config server

Handling large configuration files exceeding cache limits

Solutions

Use distributed caching (e.g., Redis cluster) to scale cache layer horizontally

Implement efficient cache invalidation with pub-sub or event-driven updates

Scale authentication service horizontally and use token caching

Deploy config servers closer to microservices (regional replicas)

Split large config files into smaller modular files and load on demand

Interview Tips

Time: Spend 10 minutes understanding requirements and clarifying scope, 20 minutes designing architecture and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.

Explain why centralized config management is important for microservices

Discuss how caching improves performance and reduces load

Highlight security considerations for config access

Describe versioning and rollback mechanisms

Address how to handle config updates and notifications

Talk about scaling challenges and solutions

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