Trocar o host de uma API em produção sem interrupção é possível, mas exige tratar a mudança como uma implantação com seu próprio perfil de risco, e não como uma edição de configuração de uma linha enviada direto para produção. A diferença entre uma virada tranquila e um incidente está quase sempre na preparação, e não no momento da troca em si.
Antes da virada:
Providencie as credenciais do novo host com bastante antecedência e confirme que elas funcionam em um ambiente de staging ou de teste com padrões de requisição reais, e não apenas com uma única chamada de teste manual
Instrumente sua aplicação para registrar qual host atendeu cada requisição, mesmo que temporariamente, para que você possa verificar o andamento da implantação e diagnosticar qualquer problema por host depois
Confirme que seu sistema de configuração permite alterar o valor do host sem uma nova implantação completa da aplicação, seja por uma variável de ambiente, uma feature flag ou um serviço de configuração remota, já que um processo que exige uma nova implantação a cada mudança reage mais devagar se algo der errado no meio da virada
Durante a virada:
Aplique a mudança gradualmente, e não de uma vez, se sua infraestrutura permitir: uma porcentagem do tráfego, um servidor ou uma região por vez, ou um endpoint não crítico antes dos demais
Acompanhe as taxas de erro e os tempos de resposta em tempo real durante a janela de implantação, comparando-os diretamente com sua linha de base de antes da virada, e não com uma faixa aceitável presumida
Mantenha as credenciais do host anterior ativas e prontas durante essa janela, para que reverter seja uma mudança de configuração, e não uma nova implantação
Depois da virada:
Deixe o novo host rodar com todo o tráfego por um período de observação definido antes de considerar a migração concluída, já que alguns problemas só aparecem sob carga contínua ou em determinados horários do dia
Compare os dados de resposta reais entre o host antigo e o novo para uma amostra de requisições idênticas, se você registrou ambos, para detectar diferenças sutis nos dados que as taxas de erro sozinhas não revelariam
Só aposente as credenciais do host antigo depois que o período de observação tiver passado sem problemas, em uma data específica e decidida, e não "algum dia"
Como os hosts de compatibilidade do My Geocode reproduzem o formato exato de requisição e de resposta de um provedor, a mudança real no código em uma migração baseada em compatibilidade frequentemente se limita ao nome do host e à credencial de autenticação, o que reduz a quantidade de código novo introduzido durante a parte mais arriscada da janela de virada. A própria autenticação aceita quatro estilos, cabeçalho X-API-Key, Authorization: Bearer, HTTP Basic auth ou um parâmetro de query, então essa parte da mudança muitas vezes pode ser uma simples atualização de configuração, sem nenhuma alteração de código, dependendo de como sua biblioteca cliente atual está estruturada.
Uma migração sem downtime depende menos de uma infraestrutura engenhosa e mais de disciplina: prepare-se bem, implante gradualmente, acompanhe de perto e mantenha um caminho de volta até ter confiança suficiente para não precisar dele.
Automações no-code construídas sobre uma etapa de geocodificação exigem uma abordagem de migração diferente da usada em código próprio. Veja como lidar com essa troca.
Trocar de fornecedor de dados de localização não é apenas uma decisão técnica. Veja o que revisar do lado do processamento de dados e da privacidade nessa mudança.
Desligar a chave de API de um provedor antigo cedo demais ou tarde demais traz riscos nos dois casos. Veja como aposentar credenciais corretamente quando uma migração estiver concluída.