Zero downtime na atualização de APIs

O que significa zero downtime na prática?

Downtime é o tempo em que um serviço fica fora do ar. Zero downtime, portanto, quer dizer que a atualização acontece sem que ninguém perceba uma parada. A API continua aceitando chamadas enquanto a versão nova entra no lugar da antiga.

Para quem consome a API, como um ERP ou uma plataforma de vendas, o efeito esperado é simples: as requisições seguem funcionando antes, durante e depois da atualização, sem mensagens de serviço indisponível e sem necessidade de reprogramar horários de envio.

Por que isso é importante em uma API fiscal?

A emissão de documentos fiscais costuma estar no meio de processos que não podem esperar. Uma NFC-e precisa ser autorizada enquanto o cliente está no caixa, uma NF-e precisa sair antes de a mercadoria deixar o estoque e um MDF-e precisa existir antes de o caminhão partir.

Se a API fiscal parasse a cada atualização, o sistema do cliente teria que acumular pedidos, avisar operadores ou recorrer a contingências. Atualizar sem interrupção reduz esse risco e permite que correções e adaptações a novas notas técnicas sejam publicadas com mais frequência e menos impacto.

Como funciona uma atualização sem interrupção?

Em vez de desligar o servidor antigo e ligar o novo, a infraestrutura mantém as duas versões convivendo por um período. Técnicas comuns incluem a troca gradual de instâncias, uma de cada vez (rolling update), a preparação de um ambiente completo paralelo para depois redirecionar o tráfego (blue-green) e a liberação da versão nova para uma pequena parte das requisições antes de ampliar (canary).

Alguns mecanismos sustentam essas técnicas: healthchecks confirmam que a nova instância está pronta antes de receber tráfego, o balanceador de carga só direciona chamadas para instâncias saudáveis e as instâncias antigas terminam as requisições em andamento antes de serem desligadas. Orquestradores como o Kubernetes automatizam boa parte desse processo.

Qual a diferença entre zero downtime e janela de manutenção?

Na janela de manutenção, o provedor avisa com antecedência que a API ficará indisponível ou instável em determinado horário, geralmente de madrugada, e os integradores se planejam para não enviar requisições nesse período.

No zero downtime, a ideia é dispensar essa pausa. Ainda assim, alguns provedores mantêm janelas para mudanças muito profundas, como migrações de banco de dados, que são difíceis de fazer sem nenhum efeito. As duas abordagens podem conviver.

Zero downtime garante que nenhuma emissão vai falhar?

Não. A prática evita paradas causadas pela atualização da própria API, mas não controla fatores externos. Se a SEFAZ ou a prefeitura autorizadora estiver instável, a emissão pode demorar ou ser rejeitada, independentemente de como a API foi atualizada.

Por isso, o sistema integrador continua precisando de boas práticas próprias: retry com backoff exponencial para erros temporários, idempotência para não emitir a mesma nota duas vezes e consulta de status para acompanhar documentos processados de forma assíncrona.

O que muda para quem integra com a API?

Para o integrador, zero downtime só funciona bem quando vem acompanhado de compatibilidade retroativa. Isso significa que a nova versão da API aceita os mesmos formatos de requisição da anterior, e mudanças que quebram contratos são publicadas em versões separadas, com prazo para migração.

Na prática, vale manter timeouts razoáveis, tratar respostas de erro temporário sem interromper o fluxo e acompanhar os comunicados do provedor sobre versões e descontinuações.

Exemplos de Zero downtime na atualização de APIs

• Um ERP envia lotes de NF-e durante o horário comercial enquanto o provedor da API fiscal publica uma correção de validação; as instâncias são trocadas gradualmente e nenhuma requisição recebe erro de indisponibilidade.
• Uma rede de varejo emite NFC-e em vários caixas ao mesmo tempo e não precisa ativar contingência porque a atualização da API ocorreu com o tráfego sendo redirecionado apenas para servidores já prontos.
• Um provedor libera uma adaptação a uma nova nota técnica primeiro para uma pequena parcela das requisições, monitora as taxas de erro e só depois amplia para todos os clientes.
• Uma transportadora mantém a emissão de CT-e e MDF-e rodando durante a madrugada sem precisar consultar um calendário de manutenção, pois a API é atualizada sem pausas programadas.