O cache é uma otimização sensata e comum para geocodificação, já que os mesmos endereços costumam ser consultados repetidamente e há pouco motivo para pagar ou esperar por uma nova consulta toda vez. Mas um cache formado ao longo de meses ou anos com os resultados de um provedor cria um problema específico durante uma migração: o que acontece com todos esses dados em cache quando o provedor por trás deles muda.
A posição geral mais segura é que resultados em cache ligados à precisão de coordenadas, às convenções de formatação de endereços ou à confiança de correspondência de um provedor específico não devem ser tratados silenciosamente como equivalentes aos resultados de um novo provedor, mesmo que o novo provedor seja, de modo geral, preciso. A precisão das coordenadas, em particular, pode variar sutilmente entre provedores, e uma aplicação que armazena em cache uma latitude e longitude com várias casas decimais pode estar dependendo de características de precisão específicas do provedor que gerou originalmente esse número.
Algumas abordagens práticas, em ordem aproximadamente crescente de rigor:
Como os resultados de geocodificação direta, em particular, podem variar em formatação exata e precisão entre provedores, este é um caso em que testar uma amostra significativa dos seus endereços realmente armazenados em cache no novo provedor, antes da troca completa, é mais valioso do que testar com endereços sintéticos ou escolhidos a dedo. Os dados reais em cache refletem os seus padrões reais de uso, com casos extremos e tudo.
Os hosts de compatibilidade do My Geocode retornam os dados na mesma estrutura de campos do provedor original, então qualquer código que leia e armazene entradas de cache pelo nome do campo não deve precisar de reestruturação durante uma migração; apenas os próprios valores podem variar ligeiramente entre provedores para um determinado endereço. Os cabeçalhos de cota presentes em cada resposta, entre eles X-Quota-Used e X-Credits-Remaining, documentados em /docs/rate-limits/, também valem ser considerados em um plano de invalidação de cache, já que uma onda repentina de cache misses se traduz diretamente em um pico no volume de requisições, e dosar essa onda de acordo com a sua cota é uma parte pequena, mas realmente útil, do planejamento da migração.
Tratar a migração do cache como um pequeno projeto próprio, e não como algo secundário que acontece automaticamente quando a troca de provedor entra no ar, evita uma classe de problemas sutis de qualidade de dados que são muito mais difíceis de diagnosticar depois do que de planejar com antecedência.