← Lessons

quiz vs the machine

Gold1400

System Design

Design a Remote Config Service

Push runtime configuration to clients safely with versioning and fast rollback.

5 min read · core · beat Gold to climb

Requirements

  • Change application configuration at runtime without a redeploy.
  • Deliver config to many clients with low latency.
  • Version changes and roll back quickly if something breaks.

High level design

Config is authored centrally, versioned, and distributed to clients via cache and CDN.

  • Authoring: an admin edits config values which are validated and stored as an immutable version.
  • Distribution: clients fetch the current config bundle, cached at the edge and refreshed on a schedule or push.
  • Versioning: each publish creates a new version so rollback is just pointing clients at the previous one.

Bottlenecks

  • Fetch volume: many clients polling is absorbed by edge caching with conditional requests.
  • Bad config: validate on publish and stage to a canary group before a full rollout.
  • Staleness: clients keep the last good config so a fetch failure does not break them.

Tradeoffs

  • Aggressive caching reduces load but increases propagation delay.
  • Immutable versions cost extra storage but make rollback instant and safe.

Key idea

A remote config service publishes immutable versioned bundles distributed through edge caches, making rollout a fetch and rollback a version pointer change.

Check yourself

Answer to earn rating on the learn ladder.

1. Why store config as immutable versions?

2. Why keep the last good config on the client?