Designing a Configuration Management System

A centralized configuration system allows services to read runtime config without redeployment.

Requirements

• Centralized config for 500+ services
• Changes propagate in <5 seconds
• Versioning + rollback
• Per-environment configs (dev, staging, prod)
• Access control

Architecture

Config Admin UI
    ↓
Config Service API
    ↓
  etcd / DynamoDB (storage)
    ↓
  Event Bus (changes)
    ↓
Service Config SDK
  (poll or push)

Config SDK Pattern

# Service uses config SDK
config = ConfigClient(service='order-service', env='prod')

max_retry = config.get('max_retries', default=3)
fee_rate = config.get('payment.fee_rate', default=0.029)

# SDK automatically refreshes config every 30s

Hot Reload (Push Model)

Admin changes config
    ↓
Config Service stores in etcd
    ↓
etcd watch triggers event
    ↓
Config Service pushes to connected services via SSE/WebSocket
    ↓
Service reloads config in-memory (no restart)

Versioning

config_versions:
  v1: { max_retries: 3, timeout: 5000 }
  v2: { max_retries: 5, timeout: 3000 }
  v3: { max_retries: 5, timeout: 3000, feature_x: true }

Current: v3
Rollback: → v2 (one command)

Per-Environment

Namespace: service_name/environment/key

order-service/prod/max_retries = 5
order-service/staging/max_retries = 3
order-service/dev/max_retries = 1

Access Control

Service accounts: Read-only own namespace
Ops team: Read/write all namespaces
Admin: Full CRUD + version management

Conclusion

etcd-backed config with push propagation and versioning enables safe, instant configuration changes across fleets of services.