Skip to content

Configuration Service#

Problem statement (interviewer prompt)

Design a configuration service that stores feature toggles + tuning parameters + secrets for 1000s of microservices. Clients read at startup + watch for live updates within seconds. Versioned, audited, RBAC-controlled, and partitioned by environment + region.

flowchart LR
  ADM[Admin]
  CFG[Config Service]
  KV[(Versioned KV)]
  CL([Clients / Sidecars])
  ADM --> CFG --> KV
  CL --> CFG
  CFG -. watch / push .-> CL

    classDef client fill:#dbeafe,stroke:#1e40af,stroke-width:1px,color:#0f172a;
    classDef edge fill:#cffafe,stroke:#0e7490,stroke-width:1px,color:#0f172a;
    classDef service fill:#fef3c7,stroke:#92400e,stroke-width:1px,color:#0f172a;
    classDef datastore fill:#fee2e2,stroke:#991b1b,stroke-width:1px,color:#0f172a;
    classDef cache fill:#fed7aa,stroke:#9a3412,stroke-width:1px,color:#0f172a;
    classDef queue fill:#ede9fe,stroke:#5b21b6,stroke-width:1px,color:#0f172a;
    classDef compute fill:#d1fae5,stroke:#065f46,stroke-width:1px,color:#0f172a;
    classDef storage fill:#e5e7eb,stroke:#374151,stroke-width:1px,color:#0f172a;
    classDef external fill:#fce7f3,stroke:#9d174d,stroke-width:1px,color:#0f172a;
    classDef obs fill:#f3e8ff,stroke:#6b21a8,stroke-width:1px,color:#0f172a;
    class CL client;
    class ADM,CFG service;
    class KV datastore;

flowchart TB
  subgraph Admin
    UI([Web UI])
    CLI
    API[REST API]
    GITOPS[Git source of truth]
  end

  subgraph Core
    CFG[Config Service]
    AUTH[AuthN / AuthZ]
    VAL[Schema validation]
    REVIEW[Approval / 4-eyes]
    HIST[(Version history)]
    PROMO[Promotion: dev -> stage -> prod]
  end

  subgraph Store
    KV[(Versioned KV<br/>etcd / Consul / S3)]
    PUBSUB[[Pub/Sub on key changes]]
    LABELS[Targeting: env / region / cohort]
  end

  subgraph Clients[Client tier]
    SDK([Client SDK])
    AGENT[Sidecar agent / Sidekick]
    CACHE[Local cache + TTL fallback]
    WATCH[Watch / long-poll / xDS]
  end

  subgraph Safety
    AUDIT[Audit + diff log]
    ROLL[Rollback / kill switch]
    CANARY[Canary rollout %]
  end

  Admin --> Core --> Store
  Store --> Clients
  Safety --- Core

    classDef client fill:#dbeafe,stroke:#1e40af,stroke-width:1px,color:#0f172a;
    classDef edge fill:#cffafe,stroke:#0e7490,stroke-width:1px,color:#0f172a;
    classDef service fill:#fef3c7,stroke:#92400e,stroke-width:1px,color:#0f172a;
    classDef datastore fill:#fee2e2,stroke:#991b1b,stroke-width:1px,color:#0f172a;
    classDef cache fill:#fed7aa,stroke:#9a3412,stroke-width:1px,color:#0f172a;
    classDef queue fill:#ede9fe,stroke:#5b21b6,stroke-width:1px,color:#0f172a;
    classDef compute fill:#d1fae5,stroke:#065f46,stroke-width:1px,color:#0f172a;
    classDef storage fill:#e5e7eb,stroke:#374151,stroke-width:1px,color:#0f172a;
    classDef external fill:#fce7f3,stroke:#9d174d,stroke-width:1px,color:#0f172a;
    classDef obs fill:#f3e8ff,stroke:#6b21a8,stroke-width:1px,color:#0f172a;
    class UI,SDK client;
    class API,GITOPS,CFG,AUTH,VAL,REVIEW,PROMO,LABELS,AGENT,CACHE,WATCH,AUDIT,ROLL,CANARY service;
    class HIST datastore;
    class PUBSUB queue;
    class KV storage;

Glossary & fundamentals#

Concepts referenced in this design. Each row links to its canonical page; the tag column shows whether it is a high-level (HLD) or low-level (LLD) concept.

Tag Concept What it is Page
HLD Pub/Sub & message brokers topics, consumer groups, delivery semantics pub-sub-pattern
HLD Realtime protocols WS / SSE / polling / gRPC streaming realtime-protocols
HLD Service mesh sidecar mesh, mTLS, traffic policy service-mesh
LLD REST API design verbs, statuses, pagination, errors rest-api-design

Quick reference#

Functional#

  • Versioned KV (per env/region).
  • Schema validation, approval workflow.
  • Watch / push to clients.
  • Canary rollout, rollback, audit.

Non-functional#

  • Push propagation < 5 s.
  • High read fan-out.
  • Survive registry failure with stale-OK cache.

Trade-offs#

  • Strong consistency for writes; eventual push to clients with reconcile loop.
  • GitOps vs runtime UI: prefer GitOps for prod, UI for ops only.
  • Per-tenant secrets live in dedicated vault (KMS, Vault), not the config service.

Refs#

  • Spring Cloud Config; HashiCorp Consul KV; AWS AppConfig.
  • Netflix Archaius (config patterns).
  • LaunchDarkly / Optimizely (overlap with feature flags).

FAQ#

How does a configuration service work?#

Clients fetch config at startup and subscribe to live updates via long-poll or push. The server stores versioned config in a backing store and broadcasts deltas within seconds.

What is the difference between a config service and a feature flag service?#

Feature flags target users with rules and percentages. A config service holds tuning parameters and operational settings shared across services with full versioning and audit.

How does a config service support rollback?#

Every change creates a new immutable version. Rollback is a one-click revert that reapplies a prior version and pushes it to all subscribers without redeploying services.

How are environments isolated in a config service?#

Config is partitioned by environment and region with RBAC controls so a staging update never accidentally reaches production. Promotion is an explicit, audited workflow.

Why use long-poll or push for config updates?#

Long-poll and push deliver new values within seconds without clients hammering the server. They also let the service propagate hotfixes without restarts.

How does a config service stay highly available?#

Clients cache the last known good config locally so they keep running even when the config service is down, and the service itself runs on a quorum-replicated store.