Feature Toggle Automation at CDN Edge: LaunchDarkly and Custom Flag Systems

Last Black Friday, we needed to kill a new image optimization pipeline for 12% of our traffic without redeploying a single origin server. The flag flipped at the edge in under 400ms, and our error rate dropped before most users ever noticed. That's when my team stopped thinking of feature toggles as an application-layer concern. If you're still routing every feature flag decision through origin, you're adding latency you don't need and risk you can't afford.

Why Feature Flags Belong at the Edge, Not Just the Origin

For years, I've managed feature toggles the traditional way: application code checks a flag service, origin returns a different response. It works, but it means every single request pays the round-trip cost to origin just to find out which variant to serve. When you're handling 200k requests per second across 40 PoPs, that extra 30-50ms per flag evaluation adds up fast. We measured it on one of our media clients — moving just three boolean flags from origin logic to edge evaluation shaved 28ms off p95 latency for cached content.

CDN feature management flips that model. Instead of asking origin what to do, the edge worker or edge dictionary makes the decision before the request ever leaves the PoP. You get instant rollouts, instant rollbacks, and you don't have to purge cache or redeploy. I've used this pattern for everything from A/B testing new checkout flows to gradually rolling out Brotli vs. Zstd compression. The trick is treating your edge configuration as code, not as a manual toggle in a dashboard. If your flag definitions aren't versioned and tested like your infrastructure, you'll get drift. My current setup keeps all flag schemas in Git and applies them through pipelines, much like I describe for CDN Infrastructure with Pulumi: Type-Safe CDN Configuration in Real Programming Languages — same principles, just applied to flags instead of cache rules.

// Cloudflare Worker - edge flag evaluation with local fallback
// Flags are hydrated from KV every 30s, no origin call on request path
export default {
  async fetch(request, env) {
    const flags = await env.FLAG_STORE.get("prod-flags", "json");
    const userKey = request.headers.get("x-user-id") || "anonymous";
    
    // Simple deterministic bucketing at the edge
    const bucket = hashToBucket(userKey, 100);
    const enableNewImagePipeline = flags.new_image_pipeline.enabled 
      && bucket < flags.new_image_pipeline.rollout_percent;

    if (enableNewImagePipeline) {
      return fetch(request, { cf: { cacheKey: request.url + "-v2" } });
    }
    return fetch(request);
  }
}

function hashToBucket(key, buckets) {
  let hash = 0;
  for (let i = 0; i < key.length; i++) {
    hash = ((hash << 5) - hash) + key.charCodeAt(i);
    hash |= 0;
  }
  return Math.abs(hash) % buckets;
}

Wiring LaunchDarkly Decisions Into Edge Workers

LaunchDarkly is the obvious choice if you don't want to build your own targeting engine, and I've run it at the edge for two high-traffic e-commerce sites. You don't run the full Node SDK at the PoP — that would kill your cold start time. Instead, you use LaunchDarkly's Edge SDKs or the simpler approach: bootstrap flag values into edge storage via webhook. We had LaunchDarkly push flag updates to an API Gateway endpoint that wrote directly to Cloudflare KV and Fastly Edge Dictionaries. That gave us sub-second propagation without giving every edge worker a direct dependency on LaunchDarkly's API.

The pattern I settled on looks like this: LaunchDarkly remains the source of truth for product managers and targeting rules, but the CDN is the enforcement point. A tiny relay service listens for LaunchDarkly flag change webhooks, transforms the flag payload into a compact JSON evaluated by the edge, and writes it to KV. The edge worker then does a local KV read — typically 1-5ms — and evaluates. You keep all of LaunchDarkly's percentage rollouts, prerequisite flags, and user segmentation, but you don't pay the 20-40ms cross-region API call on every request. For teams already managing infrastructure as code, this relay can be deployed declaratively alongside your distribution, similar to how you'd manage CDN Resources in CloudFormation: AWS-Native Infrastructure as Code for Content Delivery with automated drift detection. And if you're curious how this interacts with caching, the HTTP Working Group Specifications are essential reading — especially the sections on Vary and Cache-Control — so your flags don't accidentally create cache fragmentation.

# Relay service: Transform LaunchDarkly webhook -> Edge KV
# Deployed as Lambda@Edge / Cloudflare Worker triggered by webhook
import json
import hashlib

def handle_launchdarkly_webhook(event, context):
    payload = json.loads(event['body'])
    flag_key = payload['key']
    flag = payload['flag']
    
    # Simplify LaunchDarkly flag to edge-optimized structure
    edge_flag = {
        "key": flag_key,
        "enabled": flag['environments']['production']['on'],
        "rollout_percent": extract_rollout(flag),
        "rules": simplify_rules(flag['environments']['production']['rules']),
        "version": payload['version'],
        "updatedAt": payload['timestamp']
    }
    
    # Write to Fastly Edge Dictionary via API
    # Propagation is typically < 2 seconds globally
    fastly_client.update_dictionary_item(
        dictionary_id="flag_store",
        item_key=flag_key,
        item_value=json.dumps(edge_flag)
    )
    
    # Also invalidate local worker cache via purge tag
    return {"statusCode": 200, "body": "Flag synced to edge"}

def extract_rollout(flag):
    # Pull percentage from LaunchDarkly fallthrough rule
    fallthrough = flag['environments']['production']['fallthrough']
    return fallthrough.get('rollout', {}).get('percentage', 100)

When Off-the-Shelf Doesn't Cut It: Custom Flag Stores on Edge Dictionaries

I'll be honest — LaunchDarkly isn't always the right answer. For one of our video streaming clients, the per-MAU cost didn't make sense when we needed 80+ flags evaluated for anonymous users at the edge. We built a custom system using Fastly Edge Dictionaries and Cloudflare Workers KV instead. It cost us about three weeks of engineering time, but gave us complete control over payload size and evaluation logic. The architecture is simple: a Git repo holds YAML flag definitions, CI validates and pushes them to edge storage via API, and workers read them locally. No external vendor on the critical path.

The biggest lesson wasn't technical, it was operational. With a custom system, you own everything — targeting consistency, audit logs, and the UI. We cheated a bit by building a tiny internal dashboard that reads from the same KV store our edge workers use, so what product sees is exactly what the edge evaluates. We automated promotion from staging to production with CDN Automation with Ansible Playbooks: Configuration Management at Edge Scale, which let us run canary checks before a full global rollout. One thing I always remind teams: keep your flag payloads small. We learned this after a 45KB flag JSON blew up our worker memory limits — now we store flags as compressed, hashed buckets and hydrate full rules only when needed. The web.dev Articles on edge performance and caching strategies helped us tighten that budget, particularly around reducing JavaScript execution time at the edge.

Performance is where a custom store really shines if you design it right. You're not serializing LaunchDarkly's full flag model; you're storing exactly what the edge needs. In production, we've consistently seen faster propagation and lower evaluation overhead compared to a direct vendor SDK call. Here's what that trade-off looked like in our last head-to-head test across 18 million requests:

Putting It Together: A Production-Ready Edge Flag Worker

Alright, let's get practical. You've got your flag store — whether it's LaunchDarkly's edge SDK or a custom KV — now you need to make the worker actually *fast*. The biggest mistake I see teams make is doing a blocking fetch to the flag API on every request. Don't do that. You'll add 80-120ms of origin-like latency right back at the edge, which defeats the whole purpose. Instead, you want to evaluate locally from a replicated store and only revalidate asynchronously.

Our standard pattern is to bake flags into Cloudflare KV, Fastly Edge Dictionary, or Akamai EdgeKV with a 30-60 second TTL and serve stale-while-revalidate. The worker reads from the local replica in under 5ms (we're typically seeing 1-2ms for KV reads at p95), evaluates the ruleset, and then fires a non-blocking fetch to refresh if the entry is stale. This gives you flag propagation in under 45 seconds globally without ever blocking the hot path. For gradual rollouts, we hash a stable ID — usually a cookie or `cf-connecting-ip` fallback — to keep bucketing consistent. That way a user doesn't flip-flop between variants as they hit different POPs.

If you're managing edge configs declaratively, this is where your CDN Configuration Templating: Jinja2, HCL, and Go Templates for Edge Configs pipeline really pays off. We template the worker bundle itself so the default flag values and kill-switches are versioned alongside the infrastructure. And if you're still on Chef or Puppet for your origin shield layer, the same principle applies — keep your flag defaults in sync with your CDN Configuration with Chef: Recipe-Based Infrastructure for Content Delivery or CDN Puppet Management for Edge Nodes: Declarative Configuration at Scale recipes so a complete KV outage still fails safe.

// Cloudflare Worker - Local flag evaluation with SWR
export default {
  async fetch(request, env, ctx) {
    const flagKey = 'new-checkout-flow';
    const userId = request.headers.get('x-user-id') || getHashedIP(request);
    
    // 1. Non-blocking local read (<2ms p95)
    let flag = await env.FLAG_STORE.get(flagKey, { type: 'json', cacheTtl: 60 });
    
    // 2. Stale-while-revalidate: refresh in background if older than 30s
    if (isStale(flag?.meta?.timestamp, 30000)) {
      ctx.waitUntil(refreshFlag(flagKey, env));
    }
    
    // 3. Deterministic bucketing for 10% rollout
    const enabled = evaluateFlag(flag, userId); // hash-based, sticky
    
    if (enabled) {
      request.headers.set('x-flag-variant', 'v2');
      return fetchWithVariant(request, 'v2');
    }
    return fetch(request);
  }
}

function evaluateFlag(flag, userId) {
  if (!flag || flag.killSwitch) return false;
  if (flag.percentage === 100) return true;
  const bucket = hashToPercent(`${flag.key}:${userId}`); // 0-99
  return bucket < flag.percentage;
}

Advanced Patterns and Troubleshooting When Flags Go Wrong

Once you're running flags at the edge, you'll run into the fun stuff: inconsistent rollouts, cache poisoning, and the dreaded "it works for me" bug. The most common issue we debug is percentage rollouts that aren't sticky. If you're using a random number instead of a hash of a stable user key, you'll see 10% of *requests* get the new experience, not 10% of *users*. That'll thrash your origin cache and skew your A/B metrics by 15-20%. Always hash, and always use the same salt across all POPs. And set your CDN cache key to include the flag variant — e.g., `cacheKey += flagVariant` — or you'll serve the V2 HTML from cache to V1 users.

Another pattern we rely on heavily is the automatic kill switch with synthetic monitoring. Don't depend on a human to flip a flag when latency spikes. We tie our Datadog or Grafana alerts directly to a flag automation webhook. If p95 TTFB for the `new-image-optimizer` variant exceeds 250ms for more than 2 minutes, the webhook sets `killSwitch: true` in the KV and purges it globally. Propagation is typically 5-8 seconds on Fastly and Cloudflare, which is way faster than a full worker redeploy that can take 60-90 seconds. You should also sample your flag decisions — log 1% of `x-flag-variant` evaluations to your edge logs. When a customer reports a bug, you can instantly correlate it to the variant without logging every request and blowing up your log volume by 3x.

Finally, watch your edge KV limits. Cloudflare KV will handle about 1,000 writes per second per key, but if you're updating a single flag object on every experiment change, you'll hit consistency delays. We've moved to sharding flags by region or by product area — `flags:checkout:*` vs `flags:search:*` — and saw replication lag drop from ~12 seconds to under 4 seconds. For LaunchDarkly users, be careful with the edge SDK's bootstrap payload size; we've seen teams push 500KB+ of flag rules to the edge, which adds 20-30ms of initialization time on cold starts. Prune unused flags quarterly. If your payload is over 150KB, it's time for cleanup.

Frequently Asked Questions