Características Flags y lanzamiento de fich

Feature Flag (FF) es una condición administrada que activa/desactiva el comportamiento del sistema sin liberación de código. Las banderas permiten: lanzar fichas de forma segura, dirigir grupos de usuarios/mercados/tenantes, desactivar rápidamente componentes problemáticos, realizar experimentos y configurar parámetros en el rantime.

• Reducir blast radius en lanzamientos.
• Separar despliegue y activación.
• Dar una gestión transparente de los cambios con auditoría, SLO y «en un solo clic».

1) Tipos de banderas y cuándo aplicarlas

Release flags es la incorporación por etapas de un nuevo fichi (dark → canary → ramp-up → 100%).
Ops/kill-switch: desactivación instantánea de dependencias (proveedor, subsistema, computación pesada).
Experiment (A/B, multi-variant): divide el tráfico en variantes (weights, sticky bucketing).
Permission/Entitlement - Acceso a las fichas por funciones/planes/jurisdicciones.
Config remoto: parámetros de comportamiento (umbral, tiempo de espera, fórmula) del indicador/configuración.
Migration flags - Alternar esquemas/rutas de datos (moverse a un nuevo índice/DB/endpoint).

Anti-patrón: la misma bandera «pro-todo» - aplastar en ficha, el switch compuesto y los parámetros.

2) Modelo de datos de bandera (mínimo)

yaml flag:
key: "catalog. new_ranker"
type: "release"    # release      ops      kill      experiment      permission      config     migration description: "New Directory Ranking"
owner: "search-team@company"
created_at: "2025-10-01T10:00:00Z"
ttl: "2026-01-31" # delete deadline after 100% enable rules:
- when:
tenant_id: ["brand_eu","brand_latam"]
region: ["EE","BR"]
user_pct: 10 # progressive percentage then: "on"
- when:
kyc_tier: ["unverified"]
then: "off"
variants: # for experiments
- name: "control"; weight: 50
- name: "v1"; weight: 30
- name: "v2"; weight: 20 payload:
v1:
boost_freshness: 0. 3 boost_jackpot:  0. 2 v2:
boost_freshness: 0. 2 boost_jackpot:  0. 4 prerequisites: # dependent flags/schema versions
- key: "catalog. index_v2_ready"
must_be: "on"
audit:
require_ticket: true change_window: "09:00-19:00 Europe/Kyiv"
safeguards:
max_rollout_pct: 50 # stop threshold auto_rollback_on:
p95_ms: ">200"
error_rate: ">2%"

3) Evaluación y orientación (evaluación)

Ключи таргетинга: `tenant_id, region/licence, currency, channel, locale, role, plan, device, user_id, cohort, kyc_tier, experiment_bucket`.
Orden de evaluación: prerequisites → reglas deny → reglas allow → default.
Sticky bucketing: para experimentos, hash un identificador estable (por ejemplo, 'hash (user_id, flag_key)') - para que el usuario siempre obtenga una opción.

ts result = evaluate(flag, context)  // pure function if (!prereqs_ok(result)) return OFF if (deny_match(result, ctx)) return OFF if (allow_match(result, ctx)) return resolve_variant_or_on(result, ctx)
return flag. default

4) Distribución y arquitectura FF

• SDK Server-side (recomendado): fuentes de verdad y caché en backend; unificación de la lógica.
• Evaluación Edge/CDN: orientación rápida en el perímetro (donde no hay PII/secretos).
• SDK para clientes: cuando se necesita personalización de IU, pero sólo con un contexto mínimo y sin reglas sensibles.
• Config-as-Code: almacenamiento de banderas en el repositorio, validación de CI, rollo a través de CD.

• Startup bootstrap + streaming updates (SSE/gRPC) + fallback al último snapshot.
• SLA «freshness» banderas: p95 ≤ 5 s.

5) Estrategias de lanzamiento

5. 1 Dark Launch

Ficha está habilitada, pero es invisible para el usuario; recopilamos métricas y errores.

5. 2 Canary

Incluimos 1-5% del tráfico en una jurisdicción/tenante; p95/p99, errores, conversión.
Stop conditions es el umbral de activación del autocatof por métricas.

5. 3 Progressive Rollout

10% → 25% → 50% → 100% programado con verificación manual/automática.

5. 4 Shadow / Mirroring

Duplicamos las consultas en una ruta nueva (sin efecto aparente) y comparamos resultados/latencia.

5. 5 Blue/Green + FF

Desplegamos dos versiones; la bandera rueda el tráfico y cambia las dependencias por segmentos.

6) Dependencia y consistencia de servicio cruzado

Utilice prerequisites y «banderas de salud» de preparación: índice construido, migración completada.
Coordinación a través de eventos: 'FlagChanged (flag_key, scope, new_state)'.

1. habilitar la vía de acceso → 2) comprobar las métricas → 3) incluir write/side-effects.

• Contratos de servicio: el impago debe ser seguro (fail-safe OFF).

7) Observabilidad y SLO

• `flag_eval_p95_ms`, `errors_rate`, `config_freshness_ms`.
• Métricas empresariales: 'ctr', 'conversion', 'ARPU', 'retention', guardrails (por ejemplo, incidentes RG).
• Rápidos SLO automáticos para autocatof.

Logs/tracking: agregue 'flag _ key', 'variant', 'decision _ source' (servidor/edge/client), 'context _ hash'.

Dashboards: «escalera» rollout con umbrales, heatmap de errores por segmentos.

8) Seguridad y cumplimiento

PII-minimización en contexto.
RLS/ACL: quién puede cambiar qué banderas (por dominios/mercados).
Ventanas de cambio de hora (cambiar windows) y «doble confirmación» para banderas sensibles.
Auditoría inmutable: quién/cuándo/qué/por qué (enlace ticket/incident).
Jurisdicciones: las banderas no deben eludir las prohibiciones reglamentarias (por ejemplo, incluir el juego en un país prohibido).

9) Gestión de banderas «de larga vida»

Cada bandera tiene una fecha de eliminación/TTL.
Después del 100% de habilitación: cree una tarea para eliminar las ramas de código, de lo contrario crecerá la «bandera-deuda».
Marca las banderas como 'migration '/' one-time', sepáralas de las constantes 'permission/config'.

10) Ejemplo de API/SDK del contrato

Evaluation API (server-side)

http
POST /v1/flags/evaluate
Headers: X-Tenant: brand_eu
Body: { "keys":["catalog. new_ranker","rgs. killswitch"], "context": { "user_id":"u42", "region":"EE" } }
→ 200
{
"catalog. new_ranker": { "on": true, "variant":"v1", "as_of":"2025-10-31T12:10:02Z" },
"rgs. killswitch":  { "on": false, "variant":null, "as_of":"2025-10-31T12:10:02Z" }
}

Client SDK (кэш, fallback)

ts const ff = await sdk. getSnapshot()     // bootstrap const on = ff. isOn("catalog. new_ranker", ctx)
const payload = ff. payload("catalog. new_ranker", "v1")

11) Interacción con otros circuitos

Rate limits/cupos: las banderas pueden bajar el RPS/activar el bateo durante el incidente.
Circuit breaker/degradation: kill-switchy desactiva las vías pesadas e activa la degradación.
Catálogo/personalización: las banderas cambian los pesos/reglas de clasificación (a través de Remote Config).
Migraciones de DB: las banderas traducen las lecturas/escrituras a un nuevo esquema (read-replica → dual-write → write-primary).

12) Playbooks (runbooks)

1. Incidente posterior a la inclusión del 25%

Autocatof funcionó → la bandera OFF para todo/segmento, ticket en on-call, recolección de estats, RCA.
Habilite temporalmente la degradación/rama antigua a través de la bandera de migración.

2. Crecimiento de p95 por directorio

El umbral 'p95 _ ms> 200' es autocatof; Fijar el snapshot de los logs con 'flag _ key = catalog. new_ranker`.
Habilitar señales de clasificación simplificadas (payload config).

3. Falta de conformidad con la jurisdicción

La bandera permission abrió erróneamente el juego en 'NL' - OFF + post-hecho auditoría, agregando la regla guard «región deny».

4. Varianza en A/B

Detener el experimento, realizar el análisis CUPED/stratified, rebobinar con los pesos actualizados.

13) Pruebas

Unidad: evaluación determinista de reglas/prioridades/prejubilaciones.
Contrato: diagrama de indicadores (JSON/YAML), validadores, comprobación CI antes del merget.
Property-based: «deny> allow», «más vinos especiales», bucketing estable.
Replay: reproducir contextos reales en una nueva configuración.
E2E: scripts canarios (step-up/step-down), comprobación de autocatof y auditoría de eventos.
Chaos: acantilado de streaming, snapshot obsoleto, renovación masiva de banderas.

14) Errores típicos

Lógica secreta en las banderas del cliente (fugas/sustitución).
La ausencia de TTL → el «cementerio» de banderas en el código.
Las banderas «universales» sin segmentación → no es posible localizar el problema.
No hay guardrails/autocatofos - incidentes manuales.
Dependencias incompatibles entre las marcas → bucles/rissinchron.
Evaluación de marcas en cada solicitud sin caché → ráfagas de latencia.
Sin auditoría/ventana de cambios: riesgos de cumplimiento.

15) Lista de verificación antes de la venta

• La bandera se crea con el tipo, owner, descripción, TTL y requisito de ticket.
• Las reglas de destino están definidas; 'deny' en las regiones/roles no deseados.
• Sticky bucketing es determinista; el ID ha sido seleccionado de forma estable.
• Los preponderantes y las banderas de la salud están listas; el default es seguro.
• Dashboards y alertas en p95/p99, error_rate, guardaespaldas de negocios.
• Autocatof configurado; el umbral de stop rollout y las condiciones de retroceso.
• Plan Canarias: porcentajes/etapas/ventana de cambios/responsables.
• Las confecciones se validan en CI; El francotirador está distribuido por agrupaciones/regiones.
• Documentación de soporte/producto; playbucks de incidentes.
• Plan de eliminación de ramas de código y de la propia bandera después del 100%.

16) Ejemplo de bandera «migratoria» (DB/índice)

yaml flag:
key: "search. use_index_v2"
type: "migration"
description: "Switching reads to index v2"
prerequisites:
- key: "search. index_v2_built"
must_be: "on"
rules:
- when: { tenant_id: ["brand_eu"], user_pct: 5 } then: "on"
- when: { tenant_id: ["brand_eu"], user_pct: 25 } then: "on"
safeguards:
auto_rollback_on:
search_p95_ms: ">180"
error_rate: ">1%"
ttl: "2026-02-01"

Conclusión

Feature Flags no es sólo «encendido/apagado», sino una disciplina de gestión de riesgos de cambio. Los tipos claros de banderas, la orientación determinista, las colocaciones progresivas con guardrails, el autocatof, la auditoría y el plan de eliminación hacen que las liberaciones sean predecibles y que los incidentes sean breves y controlables. Incorpore las banderas en la arquitectura como la primera clase de ciudadanos, y podrá entregar valor con más frecuencia, seguridad y sentido.