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