Operar dois provedores ao mesmo tempo costuma ser um estado deliberado e temporário durante uma migração, não uma arquitetura permanente, mas precisa de estrutura suficiente para não virar uma bagunça confusa de lógica condicional espalhada pelo código. Um checklist ajuda a manter essa fase curta e com um propósito claro.
Antes de começar a enviar tráfego real para um segundo provedor:
Confirme que os formatos de resposta dos dois provedores foram mapeados para uma estrutura de dados interna comum, para que o código da sua aplicação leia de um único formato normalizado, independentemente de qual provedor realmente respondeu a uma determinada requisição
Defina a lógica de divisão desde o início: porcentagem do tráfego, endpoints específicos, segmentos específicos de clientes ou um modo sombra, em que o segundo provedor é chamado, mas seu resultado é apenas registrado, não usado
Configure logs ou marcações separados para saber, depois do fato, qual provedor atendeu cada requisição, o que faz uma enorme diferença quando algo dá errado e você precisa saber onde procurar primeiro
Enquanto os dois provedores estiverem ativos:
Compare taxas de erro e tempos de resposta entre os dois com uma frequência regular, não apenas uma vez no início, já que o comportamento pode mudar ao longo de dias ou semanas de formas que um único teste inicial não detectaria
Fique atento a divergências nos resultados reais entre os dois provedores para a mesma entrada e tenha um processo de decisão claro para quando eles discordarem, em vez de presumir que um deles simplesmente está certo
Mantenha uma anotação contínua de qualquer padrão de requisição que se comporte de forma visivelmente diferente entre os dois, já que esses são exatamente os casos que valem testes mais completos antes de aposentar o provedor antigo
Antes de aposentar o provedor original:
Confirme que todos os caminhos de código que poderiam chamar o provedor antigo foram de fato exercitados com o novo, não apenas os casos comuns
Procure qualquer lógica de fallback fixa no código que presuma que o provedor antigo está sempre disponível, já que períodos com dois provedores às vezes deixam para trás código de fallback que ninguém se lembra de remover
Defina uma data específica para desligar o provedor antigo, em vez de deixar o período com dois provedores se arrastar indefinidamente, já que uma transição sem prazo tende a nunca terminar de fato
Os hosts de compatibilidade do My Geocode foram criados justamente para tornar a primeira metade desse processo, a normalização do formato de resposta, praticamente desnecessária se o provedor do qual você está saindo já tiver um host correspondente, já que o formato continua idêntico ao original e seu código de normalização existente (se você já tinha algum) continua funcionando sem alterações. A lista completa dos 17 hosts de compatibilidade está em /compatibility/. Toda requisição também traz cabeçalhos de cota, X-Quota-Limit, X-Quota-Used, X-Quota-Free-Remaining e outros, documentados em /docs/rate-limits/, que são úteis para a etapa de registro comparativo acima, independentemente de qual provedor esteja sendo avaliado como o segundo.
Um período com dois provedores bem conduzido é curto, bem instrumentado e termina em uma data planejada. Mal conduzido, ele se torna um elemento permanente e confuso. A diferença está quase inteiramente em seguir um checklist como este, em vez de pulá-lo sob pressão de prazo.
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.