Como a Vercel migrou o banco por trás de todo build sem parar a produção

Todo build na Vercel começa no que a empresa chama de warm pool: um conjunto de containers em standby que permite iniciar um build sem esperar por compute novo. Esse pool depende de um estado que registra quais containers estão prontos, os tokens que cada um usa para autenticar e, o mais crítico, o mapeamento que liga cada build em execução ao deployment que será cobrado. Em um post no blog da Vercel, os engenheiros Melkey Moksyakov, Janos Szathmary e Andrew Healey contam como moveram tudo isso de Redis para DynamoDB, ao vivo, sob tráfego de produção.

Estado durável num cache efêmero

Quando o pool foi construído, o Redis fazia sentido: rápido, familiar e eficiente para os padrões de acesso iniciais. O problema é que o estado ficou mais importante que o armazenamento que o guardava. Tokens e status de container podem ser reconstruídos se sumirem (um token perdido volta em cerca de dez minutos). Já o mapeamento de billing não: perdê-lo significa um build que nunca é cobrado, porque nada mais registra a qual deployment ele pertencia.

A escolha do DynamoDB veio de três características: escala on-demand que acompanha o tráfego em rajadas de deploy, TTL nativo e ausência de conexões para gerenciar em alta concorrência. O que ele não prometia era a latência do Redis, e é aí que mora toda a história.

Modelar pelo padrão de acesso, não pela estrutura antiga

No Redis, o estado usava estruturas otimizadas para velocidade: tokens em set e sorted set, um sorted set por status de ciclo de vida (pending, polling, building) e uma string ligando cada container ao deployment. Cada operação custava cerca de 1ms, e o código passou a depender dessa velocidade. Uma única passada do supply loop, que reabastece cada pool, chegava a fazer centenas de chamadas de contagem.

Em vez de carregar essas estruturas adiante, o time listou o que o código realmente pedia do estado e colocou o container no centro do modelo. O containerId virou sort key; o token virou um campo do registro, guardado como hash para que ler a tabela nunca entregue uma credencial usável. Os três sorted sets de status viraram um único campo. Duas exceções precisaram de tratamento especial: contagens por status ganharam um índice ciente de tempo (para pular containers expirados) e o mapeamento de billing ganhou uma tabela própria com leituras consistentes.

Shadow mode: validar cada escrita antes de confiar

O rollout rodou em fases atrás de feature flags: Redis-only, depois dual writes, shadow reads, DynamoDB-primary e, por fim, DynamoDB-only. Cada fase mantinha rollback aberto o máximo possível. As comparações em shadow mode diziam se os dois stores concordavam sobre os valores, algo que testes sozinhos não pegam, mas não diziam nada sobre tempo. Dashboards vigiavam taxas de match, erros de escrita, latência por query e contagens de expiração enquanto o Redis ainda servia produção.

A própria máquina de comparação causou um incidente em março: checar dois stores adicionava carga, e as contagens de status eram O(n) sem o índice ciente de tempo. Um PR quatro dias depois adicionou esse índice e o rollout seguiu. Ironicamente, quando o Redis caiu de fato mais tarde no mês, o warm pool e os tokens sobreviveram, porque já liam do DynamoDB como fonte da verdade.

A premissa que ninguém tinha escrito

O ponto mais instrutivo veio em abril, quando o supply loop começou a travar. Os dados de shadow estavam saudáveis e a latência por query parecia aceitável. O que quebrou foi um comportamento que nenhuma métrica media. No P95 do getWarmPoolTokenCount, a checagem custava 1,29ms no Redis e 5,13ms no DynamoDB. Poucos milissegundos não custam nada quando se paga uma vez. Mas o loop pagava antes de cada container, centenas de vezes por passada, esticando runs para minutos. Era um clássico N+1, e o Redis simplesmente tinha sido rápido o bastante para escondê-lo.

Como resume o retrospecto de abril: "até uma degradação de tempo de query de 1ms para 15ms no P90 poderia derrubar nossa lógica de gerenciamento do warm pool". Ninguém tinha escrito essa frase em fevereiro.

Projetar a exigência para fora

Em vez de perseguir o milissegundo do Redis, o time projetou a exigência para fora. A primeira tentativa foi batching, checar estado uma vez a cada 17 containers, número tirado direto da medição no P90. Mas o time abandonou a ideia justamente por ela codificar um ratio de latência que mudaria com a carga: mais uma dependência não escrita sobre a velocidade do store.

O que foi entregue permite que as chamadas de supply do loop rodem concorrentemente, cada pool sem esperar o anterior e trabalhando com o último estado que viu. O pior caso é criar alguns containers a mais a partir de uma foto desatualizada do pool, custo aceito e registrado no PR. Sobrepor as leituras entregou o mesmo que o batching daria, sem a constante frágil.

O que fica para quem opera build em escala

A lição mais transferível não é sobre Redis versus DynamoDB. É que copiar dados foi a parte fácil; o trabalho real foi caçar as premissas de latência que o código acumulou sobre o store antigo. Uma dependência de milissegundos que nunca foi documentada, só assumida. Vale notar que o loop já travava sob Redis, às vezes por mais de um minuto, e a telemetria mostrava isso o tempo todo. Como o pool fica à frente da demanda, nunca esteve num caminho de request que forçasse alguém a olhar, até a migração forçar.

Fonte: Vercel Changelog