Low Level Design: Config Management Service

What Is a Config Management Service?

A Config Management Service (CMS) centralizes application configuration so that services can retrieve settings at runtime without redeployment. Instead of baking environment-specific values into build artifacts, every microservice queries the CMS for its current configuration. This enables zero-downtime flag changes, A/B experiment toggles, and environment-level overrides from a single control plane.

Data Model

The core schema stores versioned key-value pairs scoped to a namespace (usually a service name) and an environment.

-- Namespaces represent a logical grouping (e.g. a service or team)
CREATE TABLE namespaces (
  id          BIGINT PRIMARY KEY AUTO_INCREMENT,
  name        VARCHAR(128) UNIQUE NOT NULL,
  owner_team  VARCHAR(64),
  created_at  TIMESTAMP DEFAULT NOW()
);

-- Every config entry is a versioned key inside a namespace+environment
CREATE TABLE config_entries (
  id           BIGINT PRIMARY KEY AUTO_INCREMENT,
  namespace_id BIGINT NOT NULL REFERENCES namespaces(id),
  environment  ENUM('dev','staging','prod') NOT NULL,
  config_key   VARCHAR(255) NOT NULL,
  config_value TEXT NOT NULL,
  version      INT NOT NULL DEFAULT 1,
  is_active    BOOLEAN NOT NULL DEFAULT TRUE,
  created_by   VARCHAR(64),
  created_at   TIMESTAMP DEFAULT NOW(),
  UNIQUE (namespace_id, environment, config_key, version)
);

-- Audit log for every mutation
CREATE TABLE config_audit (
  id           BIGINT PRIMARY KEY AUTO_INCREMENT,
  entry_id     BIGINT REFERENCES config_entries(id),
  old_value    TEXT,
  new_value    TEXT,
  changed_by   VARCHAR(64),
  changed_at   TIMESTAMP DEFAULT NOW(),
  change_note  TEXT
);

Core Workflow

Clients call GET /v1/config/{namespace}/{environment}/{key}. The service checks an in-process LRU cache keyed by namespace:env:key. On a cache miss it queries the database for the row with is_active = TRUE and the highest version, populates the cache with a short TTL (e.g. 30 seconds), and returns the value. Writes go through a two-phase process: a new row is inserted with is_active = FALSE, validated, then promoted atomically using a transaction that flips the old row inactive and the new row active. This guarantees readers always see a consistent active value.

For push-based delivery, the service maintains a WebSocket or SSE fan-out layer. When a value changes, a Kafka event is published to the config.changes topic; connected clients receive the update within milliseconds and can reload without polling.

Security and Failure Handling

All API calls require a signed JWT containing the caller service identity and its allowed namespaces. The service enforces that a caller can only read its own namespace in production. Write access requires an additional RBAC role checked against an internal policy store.

Config values may contain secrets references (e.g. ${secret:db-password}) that the service resolves at read time by calling the Secrets Manager — the raw secret never lands in the config table. Values are encrypted at rest using AES-256; the encryption key is stored in a separate KMS.

If the database is unavailable the service continues to serve stale cached values up to a configurable grace period (default 5 minutes). Beyond that it returns a 503 so callers can apply their own fallback logic. A dead-man circuit breaker prevents cascading failures if the upstream KMS or Secrets Manager is also degraded.

Scalability Considerations

Config reads are extremely read-heavy and largely cacheable. A tiered caching strategy works well: an in-process LRU cache (small, hot entries), a shared Redis cluster (namespace-level TTL), and finally the primary database as source of truth. Horizontal scaling of the API tier is trivial since all state lives in the DB and Redis. For global deployments, a read replica per region eliminates cross-region latency for the cold-cache path. Config change frequency is low (tens of writes per minute at peak), so write throughput is never a bottleneck.

Summary

A well-designed Config Management Service decouples runtime behavior from deployment artifacts, enabling rapid iteration without redeployment risk. The key design choices are: versioned and audited writes, namespace-scoped access control, multi-tier caching for low-latency reads, and graceful degradation when dependencies are unavailable.

{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “What is a config management service in system design?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “A config management service is a centralized system that stores, versions, and distributes configuration data to application services at runtime. It allows teams to change application behavior without redeploying code, supports environment-specific configs, and typically provides features like hot-reloading, access control, and audit logging.”
}
},
{
“@type”: “Question”,
“name”: “How do companies like Google and Netflix handle configuration management at scale?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Google uses systems like Borg configuration and internal tools built on top of Chubby for distributed config. Netflix uses Archaius, a dynamic property management library built on top of Apache ZooKeeper, which allows configuration changes to propagate to thousands of microservices in real time without restarts.”
}
},
{
“@type”: “Question”,
“name”: “What are the key components of a low-level design for a config management service?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Key components include: a persistent config store (e.g., a relational DB or distributed KV store like etcd), a versioning layer for config history and rollback, a pub/sub or polling mechanism for change propagation, a REST or gRPC API for read/write operations, access control with per-service or per-environment scoping, and an audit log for change tracking.”
}
},
{
“@type”: “Question”,
“name”: “How does a config management service differ from a secrets manager?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “A config management service handles non-sensitive application settings such as feature flags, timeouts, and service endpoints. A secrets manager is purpose-built for sensitive credentials like API keys, passwords, and TLS certificates, and adds encryption at rest and in transit, strict access policies, automatic rotation, and detailed audit trails. The two are often used together but serve different security requirements.”
}
}
]
}