Capítulo 34 de 54

Feature Flags em Milissegundos: Lançamentos Globais com Vercel Edge Config

Índice do Manual

Lançar uma nova funcionalidade (como um novo painel de relatórios) para toda a base de clientes do seu SaaS de uma só vez é um risco amador. A engenharia moderna exige lançamentos controlados: você libera a tela nova apenas para 10% dos clientes, ou apenas para clientes específicos, e monitora se existem bugs antes de abrir para o resto do mundo.

A ferramenta tecnológica que permite esse controle é chamada de Feature Flag (Bandeiras de Funcionalidade). Elas funcionam como "interruptores digitais".

No entanto, o erro primário visto diariamente no mercado é a equipe tentar armazenar esses interruptores criando uma tabela feature_flags no banco de dados principal (Postgres/MySQL).

Nunca gaste banda de rede, processamento e conexões preciosas do seu Banco de Dados para consultar o status de um simples interruptor visual.

Este manual decreta o uso exclusivo do Vercel Edge Config para a leitura de Feature Flags na nossa arquitetura.


1. O Custo Oculto da Latência

Se você verificar o status de uma Feature Flag no Postgres a cada vez que a página carrega, você adicionará em média de 30ms a 70ms de latência ao carregamento. Em picos de tráfego (Black Friday), milhões de consultas para ler um simples booleano (true ou false) podem sobrecarregar as conexões do banco de dados e derrubar o sistema inteiro.

O Vercel Edge Config resolve isso de forma drástica. Ele é um arquivo de dadosJSON globalmente distribuído na malha da Vercel. Isso significa que o interruptor não mora em um servidor nos EUA; ele mora no roteador da internet mais próximo do seu usuário (seja em São Paulo, Tóquio ou Londres).

O tempo de leitura de uma Feature Flag no Edge Config beira a incrível marca de zero milissegundos. Não há requisição de rede; a informação já está na Borda.

2. A Implementação Padrão

Para injetar essa alta velocidade no código, basta instalarmos o SDK oficial:

npm install @vercel/edge-config

A mágica acontece quando utilizamos o Edge Config nativamente dentro dos React Server Components (RSC) no Next.js. O código abaixo é a fundação arquitetural que deve ser seguida:

// src/app/dashboard/page.tsx
import { get } from '@vercel/edge-config';
import NovoPainel from '@/components/NovoPainel';
import PainelLegado from '@/components/PainelLegado';

export default async function DashboardPage() {
  // 1. Leitura Instantânea na Borda (< 1ms)
  // O banco de dados Postgres é completamente poupado desta consulta.
  const isNovoPainelAtivo = await get('enable_novo_dashboard');

  // 2. Roteamento Lógico
  if (isNovoPainelAtivo) {
    return <NovoPainel />;
  }

  return <PainelLegado />;
}

3. O Poder do Desligamento Instantâneo (Kill Switch)

A maior vantagem comercial dessa arquitetura é o Botão de Emergência.

Se você ativou o NovoPainel para todos os clientes e, minutos depois, os usuários começaram a relatar que a tela está travando (gerando pânico no suporte), a sua equipe de tecnologia não precisa fazer um novo deploy de código e nem mexer no banco de dados principal.

Você pode desligar o recurso manualmente pelo painel da Vercel, mas em sistemas corporativos, nós automatizamos esse Kill Switch. Usando a API da Vercel, podemos construir um botão no nosso próprio Backoffice ou conectar um Webhook no sistema de monitoramento (Sentry) para desligar a funcionalidade sozinho em caso de pico de erros.

Como Fazer: A Chamada de Desligamento Automático

Para atualizar um Edge Config em milissegundos via código (sem entrar na Vercel), basta fazer um PATCH (Update) na API oficial utilizando o seu Vercel Access Token.

Veja um exemplo prático de uma função no seu backend interno (ou webhook) que puxa o gatilho e desliga o painel defeituoso:

// src/app/api/kill-switch/route.ts
export async function POST() {
  const edgeConfigId = process.env.EDGE_CONFIG_ID;
  const vercelToken = process.env.VERCEL_ACCESS_TOKEN;

  // Atualiza a chave 'enable_novo_dashboard' para false globalmente
  const response = await fetch(
    `https://api.vercel.com/v1/edge-config/${edgeConfigId}/items`,
    {
      method: 'PATCH',
      headers: {
        Authorization: `Bearer ${vercelToken}`,
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({
        items: [
          {
            operation: 'update',
            key: 'enable_novo_dashboard',
            value: false, // 🔴 DESLIGA A FEATURE NA HORA
          },
        ],
      }),
    }
  );

  if (response.ok) {
    return Response.json({ message: 'Kill Switch Ativado. Feature desligada.' });
  }
}

Em questão de milissegundos após essa API ser chamada, a alteração se propaga para a Borda da rede mundial inteira. Quando o próximo cliente apertar F5, o painel antigo e estável já estará no ar. O estresse foi neutralizado antes da diretoria reclamar.

Um sistema B2B corporativo não tenta evitar todos os bugs; ele orquestra infraestruturas para que a reversão dos erros leve milissegundos e não seja percebida pelo cliente final.