Flagship: Evaluación de Feature Flags en el Edge con Cloudflare

La proliferación de código generado por IA y agentes autónomos en el ciclo de desarrollo exige mecanismos de despliegue y control de lanzamiento que desacoplen la atención humana de cada paso del proceso. Los feature flags, tradicionalmente usados para separar despliegue de lanzamiento, se convierten en un componente crítico para gestionar el riesgo y la experimentación en entornos de alta velocidad.

El problema fundamental que Flagship aborda es cómo realizar la evaluación de feature flags con baja latencia y alta disponibilidad en un entorno de edge computing sin estado, como Cloudflare Workers. Las soluciones tradicionales, ya sea hardcoding o llamadas a servicios externos, introducen fricción: el hardcoding carece de trazabilidad y gestión centralizada, mientras que las llamadas externas añaden latencia crítica al path de la solicitud. Las SDKs de evaluación local fallan en Workers debido a la naturaleza efímera de los isolates, que no mantienen estado en memoria entre solicitudes.

Arquitectura del Sistema

Flagship se construye sobre la infraestructura de Cloudflare: Workers, Durable Objects y KV. Cuando se crea o actualiza un flag, el plano de control escribe el cambio atómicamente en un Durable Object. Este Durable Object actúa como la fuente de verdad globalmente única y persistente, respaldada por SQLite, manteniendo la configuración del flag y su changelog. En segundos, la configuración actualizada se sincroniza con Cloudflare KV, un almacén de clave-valor distribuido globalmente, replicándose a través de la red de Cloudflare.

Durante la evaluación de un flag, Flagship lee la configuración directamente desde KV en el nodo de edge más cercano al usuario, el mismo que maneja la solicitud. El motor de evaluación se ejecuta en un isolate de Worker, comparando el contexto de la solicitud con las reglas de targeting del flag, resolviendo el porcentaje de rollout y devolviendo la variación. Tanto los datos como la lógica residen en el edge, eliminando la necesidad de llamadas de red externas para la evaluación. Para Workers, Flagship ofrece un binding directo que permite la evaluación de flags dentro del runtime sin sobrecarga HTTP. Para otros entornos, se proporciona un SDK compatible con OpenFeature que puede usar el binding o realizar llamadas HTTP a la API de Flagship. Las reglas de targeting soportan condiciones lógicas anidadas (AND/OR) y rollouts basados en porcentaje utilizando consistent hashing sobre atributos de contexto para garantizar la persistencia de la variación para un usuario dado.

export default {
  async fetch(request: Request, env: Env) {
    // Simple boolean check
    const showNewUI = await env.FLAGS.getBooleanValue('new-ui', false, {
      userId: 'user-42',
      plan: 'enterprise',
    });

    // Full evaluation details when you need them
    const details = await env.FLAGS.getStringDetails('checkout-flow', 'v1', {
      userId: 'user-42',
    });
    // details.value = "v2", details.variant = "new", details.reason = "TARGETING_MATCH"
  },
};

import { OpenFeature } from '@openfeature/server-sdk';
import { FlagshipServerProvider } from '@cloudflare/flagship/server';

let initialized = false;
export default {
  async fetch(request: Request, env: Env) {
    if (!initialized) {
      await OpenFeature.setProviderAndWait(
        new FlagshipServerProvider({ binding: env.FLAGS })
      );
      initialized = true;
    }
    const client = OpenFeature.getClient();
    const showNewCheckout = await client.getBooleanValue('new-checkout-flow', false, {
      targetingKey: 'user-42',
      plan: 'enterprise',
    });
  },
};

Fundamentos Teóricos

El problema de la consistencia y disponibilidad de datos en sistemas distribuidos, especialmente en el edge, se relaciona con el Teorema CAP. Flagship prioriza la disponibilidad y la tolerancia a particiones, sacrificando la consistencia fuerte inmediata en favor de una consistencia eventual para la configuración de flags. La replicación de configuraciones de flags a través de Cloudflare KV es un ejemplo de un sistema de clave-valor distribuido que busca alta disponibilidad y baja latencia de lectura, un patrón explorado en papers como 'Dynamo: Amazon's Highly Available Key-value Store' de DeCandia et al. (2007). La elección de Durable Objects para la fuente de verdad de los flags, que son instancias únicas y persistentes, refleja la necesidad de un punto de coordinación para la consistencia de escritura, similar a cómo se gestiona el consenso en sistemas distribuidos para garantizar la atomicidad de las actualizaciones, aunque con un modelo de consistencia eventual para las lecturas en el edge.