System 12.26 — Feature Flag Platform
In one line
Flags as a product: evaluation service with edge caching, targeting rules, audit, and kill switches.
Think of it like this
A giant panel of light switches for a company's product, where each switch turns a new feature on or off for specific users instantly, without needing to release new app code.
Key ideas
- 01
Model: flag (name, rollout %, targeting rules) evaluated per (user/context) → variant; the SDK caches evaluations.
- 02
Latency imperative: evaluation must be ~0 — SDK caches flag rules with TTL + streamed updates (fast-path local, slow-path poll).
- 03
Targeting: % rollouts, cohorts, environment, user segments; deterministic bucketing (hash(user, flag) < pct).
- 04
Kill switch: the flag to kill an experiment or cap a release — deployed instantly, no code deploy.
- 05
Audit + approval: every toggle logged (who, when, old→new) — the operationally important part (compliance).
- 06
Consistency: cached evaluations are eventual (up to TTL stale) — acceptable for flags; a 401-vs-flag mistake is not.
- 07
Scale: 10k services × evaluations per request → SDK-local hits on 100M QPS with the rules engine fanning via Redis/pub-sub.
- 08
The kill-switch-on-call story is the design justification: it converts 'deploy politics' into 'config push'.
Code & diagrams
The whole design exists to make evaluation instant — the SDK never makes a network call on the request's hot path.
Explain without notes
Why must the evaluation SDK be local + cached — and what is the acceptable staleness window for a flag?
Practice
Design the deterministic bucketing + the kill switch anatomy (instant, targeted, audited).
Trade-offs
- ↔
Flag sprawl = dead code everywhere (cleanup debt) vs the operational freedom — auto-expiry solves the debt.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I can present a flag platform: local SDK, targeting, audit, and the kill switch.