O problema das chaves de API que nunca expiram
Uma chave emitida anos atrás, nunca trocada e ainda válida hoje não é uma conveniência. É um risco que ninguém examina de verdade há anos.
O que dados de localização "em tempo real" realmente exigem
"Tempo real" é associado a muitos produtos de dados de localização como sinônimo de respostas rápidas, e a velocidade é algo real e que vale a pena otimizar. Mas é uma afirmação completamente diferente do que "tempo real" deveria significar para dados que descrevem algo sobre o estado atual do mundo: que a resposta reflete o que é verdade agora, e não uma consulta rápida e de baixa latência a um conjunto de dados que foi compilado há algum tempo e não foi atualizado de forma significativa desde então.
Essa distinção importa mais especificamente para a geolocalização de IP, porque o mapeamento entre faixas de endereços IP e sua localização física muda com o tempo, à medida que os blocos de endereços são reatribuídos, realocados ou reaproveitados pelos registros regionais de internet que os administram. Uma consulta que responde em poucos milissegundos com base em um mapeamento desatualizado é rápida e errada ao mesmo tempo, e a velocidade não faz nada para corrigir o erro. Uma geolocalização de IP realmente em tempo real exige que o próprio mapeamento subjacente seja mantido atualizado, com um processo de consulta ao vivo e um cache que é renovado, em vez de tratado como um retrato fixo e único.
Construímos a nossa geolocalização de IP especificamente em torno dessa distinção: ela funciona ao vivo, com o cache usado para manter os tempos de resposta baixos, e não como substituto da atualidade dos dados, e com um processo de novas tentativas em segundo plano que continua trabalhando nos dados que precisam ser verificados de novo, em vez de uma tarefa cron periódica servindo como o único mecanismo para manter o mapeamento atualizado. O objetivo é que o cache deixe tudo rápido sem deixar desatualizado, o que é um objetivo de projeto diferente de um cache que existe apenas para evitar recalcular qualquer coisa, atual ou não.
A mesma distinção se aplica, de outra forma, aos dados de fuso horário. Uma resposta rápida que descreve um deslocamento que não levou em conta uma transição recente de horário de verão ou uma mudança recente de regra do governo não é em tempo real em nenhum sentido significativo, mesmo que tenha voltado em dez milissegundos. Tempo real aqui significa que a referência subjacente, neste caso o banco de dados de fusos horários da IANA, é acompanhada e aplicada à medida que muda, e não que a resposta chegou rápido com base em uma tabela que ninguém mexe há tempos.
Achamos que "tempo real" merece ser tratado primeiro como uma afirmação sobre a atualidade dos dados e só depois sobre a latência da resposta, mesmo que a latência seja a parte mais fácil de medir e de demonstrar. Um provedor pode realmente otimizar o tempo de resposta para uma fração de segundo enquanto deixa, discretamente, os dados subjacentes ficarem desatualizados por meses, e, vistas de fora, uma resposta rápida errada e uma resposta rápida certa parecem idênticas até que algo mais adiante dependa da diferença. O trabalho mais difícil e menos visível é manter os próprios dados atualizados. É essa a parte que realmente merece o rótulo, e também é a parte que o cliente não consegue verificar apenas cronometrando uma requisição.