Implementing Feature Flags at the Edge with Zero Latency

Feature flags are a cornerstone of modern software delivery, empowering product teams to run canary deployments, perform A/B testing, and toggle features on-the-fly without redeploying code. However, traditional implementations introduce a stark trade-off: latency.

Client-side SDKs require extra network round-trips to fetch flag state, often causing an unpleasant "flicker" or layout shift (CLS) as elements load late. Similarly, server-side flag evaluation can delay the Time to First Byte (TTFB) if the application server must query a remote configuration API before rendering the page.

To eliminate this latency tax, engineering teams are moving feature flag evaluation to the edge. By running evaluation logic within globally distributed edge computing environments (such as Cloudflare Workers, Fastly Compute, or Vercel Edge), flags can be resolved in microseconds at the server closest to the user. This architecture allows personalized, flagged content to be dynamically served or rewritten inline, maintaining the benefits of a static site while offering dynamic, zero-latency personalization.

1. The Edge Feature Flag Architecture

Evaluating feature flags at the edge requires decoupling the flag configurations from the central database. Instead of querying a central API on every request, flag rules are synchronized to a globally distributed, edge-accessible Key-Value (KV) database or in-memory edge cache. The architectural workflow operates as follows:

• Rule Synchronization: When a developer updates a flag in a system like LaunchDarkly or a custom management dashboard, a webhook triggers a sync process that pushes the new flag rules (JSON) to the edge KV store.
• Request Interception: The user's request arrives at the nearest Edge Point of Presence (PoP).
• Context Extraction: The Edge Worker extracts user attributes from the request (e.g., user ID from cookies, geo-location from IP headers, device type from user-agent).
• Local Evaluation: The Edge Worker retrieves the flag rule configuration from the local KV and evaluates it against the user context in-memory.
• Dynamic Routing or Rewriting: Based on the resolved flag value, the worker either routes the request to a specific backend asset or streams rewritten HTML.

2. Evaluating Flags Inside an Edge Worker

To understand the mechanics, let us look at an implementation within an edge script. In this scenario, we read a user identification cookie, retrieve the flag configuration cached locally, and evaluate whether the user should see a new homepage layout.

// Example Edge Worker Script
addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
  const url = new URL(request.url);
  
  // 1. Extract user context from cookies
  const cookieHeader = request.headers.get('Cookie') || '';
  const userId = getCookieValue(cookieHeader, 'user_id') || 'anonymous_user';
  
  // 2. Fetch flag configuration from edge KV
  // In a real environment, read from a binding like: await FLAG_KV.get('homepage_redesign_rules')
  const flagConfig = {
    enabled: true,
    percentageRollout: 50,
    targetingRules: [
      { country: 'US', value: true }
    ]
  };
  
  const userCountry = request.headers.get('cf-ipcountry') || 'US';
  const isFeatureEnabled = evaluateFlag(userId, userCountry, flagConfig);
  
  // 3. Rewrite response on the fly based on flag
  let targetPath = isFeatureEnabled ? '/new-homepage.html' : '/old-homepage.html';
  const response = await fetch(url.origin + targetPath);
  
  return new Response(response.body, {
    headers: { 'Content-Type': 'text/html' }
  });
}

function evaluateFlag(userId, country, config) {
  if (!config.enabled) return false;
  
  // Target by rule
  const targetRule = config.targetingRules.find(r => r.country === country);
  if (targetRule) return targetRule.value;
  
  // Consistent hash rollout
  const hash = getSimpleHash(userId);
  return (hash % 100) < config.percentageRollout;
}

function getSimpleHash(str) {
  let hash = 0;
  for (let i = 0; i < str.length; i++) {
    hash = (hash << 5) - hash + str.charCodeAt(i);
    hash |= 0; 
  }
  return Math.abs(hash);
}

function getCookieValue(cookieHeader, key) {
  const match = cookieHeader.match(new RegExp('(^|;)\\s' + key + '=([^;])'));
  return match ? decodeURIComponent(match[2]) : null;
}

3. High-Performance HTML Rewriting at the Edge

Rather than routing to completely different HTML templates, you can use specialized tools like the Cloudflare HTMLRewriter. This utility parses and modifies the HTML stream on-the-fly, allowing you to inject flagged features or alter DOM nodes with near-zero latency, avoiding full page redirections and preserving SEO ranking.

// Example of using HTMLRewriter to rewrite a banner
const flagValue = evaluateFlag(userId, userCountry, flagConfig);
const response = await fetch(request);

return new HTMLRewriter().on('#promo-banner', {
  element(el) {
    if (flagValue) {
      el.setInnerContent('<p>Exclusive Deal: Use code EDGE20 for 20% off!</p>', { html: true });
    } else {
      el.setInnerContent('<p>Sign up today for our latest updates.</p>', { html: true });
    }
  }
}).transform(response);

4. Benefits of Edge Flag Evaluation

Shifting to edge evaluation brings tangible engineering and business rewards:

• Zero Latency: No blocking network calls. Flag resolution is computed in-memory, keeping TTFB and first contentful paint (FCP) metrics optimal.
• No Layout Flicker: Since the HTML is rewritten before it reaches the browser, users never experience structural shifts, protecting Google Core Web Vitals scores.
• Resilience: If the central flag provider goes down, edge workers fallback to cached rules stored locally inside KV, protecting website uptime.

5. Unlocking Edge Personalization at Scale with Bramsley