Cookie preferences

Essential cookies keep this site working. Optional Google Analytics cookies help us understand page visits and improve the site. You can change your choice anytime. Cookie policy

Skip to content
ForCSGuy System Design Atlas home

Library / Blogs

Feature Toggles (aka Feature Flags)

Kinds of feature flag, how to manage them and the costs of leaving them in the code.

IntermediateDeployment

By Pete Hodgson · Martin Fowler · Added 2026-10-12

Open original source

All content belongs to Pete Hodgson / Martin Fowler. We only link to it and give credit. Report a problem

Learn this article

About 37 min left. Your work is saved as you go.

What you are about to study

Martin Fowler wrote this to explain how they thought about a problem. You should know the basics: caching, queues and replication.

Ideas you will meet

Deployment
Releases, feature flags, rollbacks and continuous delivery.

What we already know about this

Our own lessons on these ideas. Read them here before you start, so it makes sense.

  • Core Concepts: How Things Actually Work · 8 minDeployment strategiesRolling, blue-green, canary and feature flags: how to release changes with less risk, including database changes.Read here

    Why strategy matters

    Most outages follow a change. A good deployment strategy limits the blast radius and makes rollback fast.

    The main strategies

    Recreate (big bang)

    Stop the old version, start the new one. Simple, but there is downtime and no easy rollback.

    Rolling update

    Replace instances a few at a time. No downtime and little extra capacity, but for a while both versions serve traffic, so they must be compatible. Rollback means rolling back the same way.

    Blue-green

    Run two identical environments. Blue serves live traffic; deploy to green, test it, then switch the router to green. Rollback is flipping back. Cost: double the capacity during the switch, and shared state (databases) still needs care.

    Canary

    Send a small share (1%, 5%, 25%...) of traffic to the new version, watch the metrics, then widen. If errors rise, roll back automatically. Needs good monitoring and traffic splitting.

    Figure SDA-CORE-12-1 · Canary · © forcsguy.com

    Feature flags

    Ship code switched off, and enable it for chosen users (or a percentage) at runtime. It separates deploying from releasing, and gives an instant kill switch. Remove old flags to avoid clutter.

    Figure SDA-CORE-12-2 · Four ways to put a new version live · © forcsguy.com

    Before: release to everyone at once

    After: canary: a few users first

    What changed

    • A bad release reaches few users before it is caught
    • Rolling back means shifting traffic back, not redeploying
    • You compare error rates between old and new

    Databases are the hard part

    Code can roll back instantly; data cannot. Use expand and contract:

    1. Expand: add new columns or tables, compatible with the old code.
    2. Deploy code that works with both shapes and writes to both if needed.
    3. Migrate data (backfill in batches).
    4. Contract: remove the old structure in a later release.

    Never combine a destructive schema change with the code that depends on it in one step.

    Checklist for safer releases

    • Automated tests and a staging environment that resembles production.
    • Health checks and automatic rollback on failure.
    • Monitoring on error rate and latency, watched during rollout.
    • Small, frequent changes over large, rare ones.
    • A written, practised rollback plan.

    More on this site

    Related reading

    Show 6 more

    Open this lesson with its quiz and exercise

  • Advanced Distributed Systems · 13 minKubernetes essentialsPods, deployments, services, ingress and operators: the building blocks of the most common container platform and how a request reaches a pod.Read here

    What Kubernetes does

    Kubernetes (K8s) runs containers across a cluster of machines. You describe the desired state (for example "three copies of this image, reachable at this address") and controllers continuously make reality match it: restarting failed containers, replacing lost nodes and rolling out new versions. (Containers themselves are introduced in the cloud models lesson.)

    The cluster

    • Control plane: the API server (everything talks to it), etcd (the consistent store of cluster state, built on Raft; see the consensus lesson), the scheduler (decides which node runs a pod) and controllers (reconcile desired and actual state).
    • Nodes: machines that run pods, each with a node agent (kubelet), a container runtime and a networking component.

    The core objects

    Figure SDA-ADS-07-1 · From request to pod · © forcsguy.com

    ObjectPurpose
    PodSmallest unit: one or more containers sharing network and volumes
    ReplicaSet / DeploymentKeep N pods running; roll out updates and roll back
    ServiceStable virtual IP and DNS name that load balances to matching pods
    IngressHTTP routing from outside to services (host, path, TLS), handled by an ingress controller
    ConfigMap / SecretConfiguration and sensitive values injected as environment variables or files
    StatefulSetPods with stable identity and storage, for databases and brokers
    DaemonSetOne pod per node (log shippers, agents)
    Job / CronJobRun to completion, once or on a schedule
    NamespaceLogical separation of resources and quotas
    PersistentVolume(Claim)Durable storage requested by pods

    Networking in one paragraph

    Every pod gets its own IP and can reach every other pod without NAT. Because pods are short-lived, clients use Services (found through cluster DNS such as orders.shop.svc). Network policies restrict which pods may talk to which. An Ingress (or the newer Gateway API) handles external HTTP(S) traffic.

    A deployment and a rolling update

    apiVersion: apps/v1
kind: Deployment
metadata: { name: web }
spec:
  replicas: 3
  selector: { matchLabels: { app: web } }
  strategy: { type: RollingUpdate, rollingUpdate: { maxSurge: 1, maxUnavailable: 0 } }
  template:
    metadata: { labels: { app: web } }
    spec:
      containers:
        - name: web
          image: example/web:1.4.2
          resources: { requests: { cpu: 200m, memory: 256Mi }, limits: { memory: 512Mi } }
          readinessProbe: { httpGet: { path: /healthz, port: 8080 } }

    Figure SDA-ADS-07-2 · Rolling update · © forcsguy.com

    Probes: readiness decides if a pod receives traffic; liveness decides if it should be restarted; startup gives slow starters time. Requests and limits tell the scheduler how much CPU and memory a pod needs and cap what it can use.

    Autoscaling

    A Horizontal Pod Autoscaler adds or removes pods by metrics such as CPU or request rate; a cluster autoscaler adds or removes nodes when pods cannot be placed. Scaling is useless without correct resource requests.

    Extending Kubernetes: operators and CRDs

    A Custom Resource Definition (CRD) adds a new object type (for example PostgresCluster). An operator is a controller that watches those objects and does the operational work (create replicas, take backups, fail over), encoding human runbooks as code. Many databases and brokers ship operators.

    Things that often go wrong

    Missing readiness probes (traffic to pods not ready), no resource requests (noisy neighbours, evictions), latest image tags (unrepeatable deploys), secrets in plain config, a single replica for a critical service, and running stateful systems without understanding storage and failure behaviour.

    Real-world reading

    Related reading

    Show 6 more

    Open this lesson with its quiz and exercise

  • System Design Foundations · 9 minObservability and running a systemMetrics, logs and traces, how to define 'healthy' with SLOs, and how to ship changes without breaking things.Read here

    You cannot fix what you cannot see

    A system you cannot observe is a system you cannot trust. Observability is the ability to understand what is happening inside from the outside. Three kinds of signal work together.

    SignalWhat it isBest for
    MetricsNumbers over time (requests per second, error rate, CPU)Dashboards, alerts, trends
    LogsTimestamped records of eventsDetails of what happened
    TracesThe path of one request through many servicesFinding where time is spent

    Figure SDA-FND-11-1 · From alert to root cause · © forcsguy.com

    What to measure

    A simple checklist, the four golden signals:

    1. Latency: how long requests take (use percentiles).
    2. Traffic: how much demand there is.
    3. Errors: how many requests fail.
    4. Saturation: how full the busiest resource is (CPU, memory, connections, disk, queue depth).

    Averages hide pain. If the average is 100 ms but p99 is 4 seconds, one user in a hundred is waiting four seconds, and with many requests per page that is most of your users sometimes.

    Defining healthy: SLIs, SLOs, error budgets

    • An SLI (indicator) is a measurement, like "fraction of requests answered successfully in under 300 ms".
    • An SLO (objective) is the target, like "99.9% over 30 days".
    • The error budget is what is left over: 0.1% of requests may fail. While there is budget, ship features; when it runs out, focus on reliability.

    Alert on symptoms users feel (error rate, latency) more than on causes (one machine's CPU). Page a human only for things that need action now.

    Ship changes safely

    Most outages come from changes. Reduce the risk:

    • Small, frequent releases are easier to understand and undo than big ones.
    • Canary release: send a few percent of traffic to the new version and watch the metrics before going wider.
    • Feature flags: deploy code turned off, then enable it gradually, and switch it off instantly if needed.
    • Blue-green: keep the old version running so you can switch back in seconds.
    • Backwards-compatible changes: database and API changes should work with both old and new code during rollout.
    • Fast rollback must be a rehearsed, boring button.

    When things go wrong

    Have an incident process: someone leads, someone communicates, mitigate first and investigate later. Afterwards write a blameless postmortem that asks "how did our system and process allow this?" rather than "who did this?". That is how reliability actually improves.

    A worked example: error budgets and burn rate

    Your service has an SLO of 99.9% of requests succeed over 30 days, and it serves 10 million requests a month.

    • Error budget: 0.1% of 10,000,000 = 10,000 failed requests may happen in the month before you break the promise.
    • Burn rate is how fast you spend it. A burn rate of 1 uses exactly the budget over 30 days. If 5% of requests are failing now, the error rate is 50 times the allowed 0.1%, a burn rate of 50: the whole month's budget is gone in 30 / 50 = 0.6 days, about 14 hours.
    • Alert on burn rate, not on a single bad minute. A common pattern watches two windows together: page someone if the burn rate over the last hour is above about 14 and the last 5 minutes agree (a fast burn: 2% of the monthly budget gone in an hour). Open a ticket for a slower burn, say rate above 6 over 6 hours. Two windows avoid paging for blips and avoid missing slow leaks.

    Why this beats "alert when error rate is above X": it ties alerts to what users were promised, it pages only when the budget is in danger, and it gives the team a rule for trade-offs: when the budget is healthy, ship faster; when it is nearly spent, slow down and fix reliability.

    Figure SDA-FND-11-2 · Alerting on how fast the error budget burns · © forcsguy.com

    Finding the cause with all three signals

    A worked investigation shows why you want metrics, traces and logs together.

    1. A metric alerts: the checkout success rate dropped and p99 latency rose. Metrics tell you that something is wrong and how bad, cheaply and over time.
    2. Narrow it down by dimension: break the metric down by region, version and endpoint. Only the new version in one region is affected, a strong hint it is a deploy.
    3. A trace shows where the time goes: one slow checkout request shows 4.8 of its 5 seconds in a call to the payment provider's tokenisation endpoint.
    4. Logs give the detail: filter logs by the trace id from that request and read the exact error: a timeout talking to a new tokenisation URL.
    5. Fix and verify: roll back the version, and watch the metric recover.

    Figure SDA-FND-11-3 · From an alert to a root cause · © forcsguy.com

    The glue is a correlation id (trace id) carried on every request and written into every log line, so you can jump from one signal to the others.

    Mistakes people make

    • Alerting on causes instead of symptoms. "CPU is 85%" may be fine; "users are seeing errors" never is. Page on symptoms users feel, and use cause metrics for diagnosis.
    • Averaging percentiles. The mean of two hosts' p99 is meaningless; merge distributions instead (see the t-digest lesson).
    • High-cardinality labels. A label such as user_id on a metric creates a new time series per user, which can multiply storage and cost by millions. Put such detail in logs or traces.
    • Logs without structure or ids. Free text is hard to query. Log JSON with a trace id, service and version.
    • Dashboards no one owns. A wall of graphs nobody reads is noise. Build a small dashboard per service around the golden signals: latency, traffic, errors and saturation.
    • No runbook. An alert that does not say what to check first wastes the first ten minutes of every incident.

    Try it yourself

    Run any test in the System Builder and read its charts as if they were production graphs: which signal moves first, and which part would you look at next? Build the search metrics lab to practise percentile maths, and read the t-digest lesson for how real systems summarise latency at scale.

    Real-world reading

    Related reading

    Show 6 more

    Open this lesson with its quiz and exercise

Continue to Martin Fowler

Go deeper on this

A path through videos, articles, other case studies and code on the same ideas as Feature Toggles (aka Feature Flags).

  1. Warm upGet the vocabulary first.

  2. WatchHow others solve the same problem, on video.

    Videos belong to their creators and play from YouTube. More on YouTube (opens in a new tab)

  3. ReadEngineers explain it in their own words.

  4. See it in another companyThe same ideas, a different system.

  5. Read the codeSee how it looks when it is real.

Keep learning

Loading community…