Banco de geolocalização de IP: autohospedado ou API
Um banco de dados de geolocalização de IP autohospedado é um arquivo que você baixa e consulta dentro do seu próprio processo, enquanto uma API de geolocalização de IP é uma chamada de rede a um provedor que mantém e atualiza os dados para você. A escolha é, em grande parte, sobre onde você prefere pagar: em trabalho operacional e disciplina de atualização, ou em latência de rede e dependência do serviço de outra pessoa.
O que envolve autohospedar um banco de IP
Com um banco de dados autohospedado, um arquivo binário (muitas vezes de algumas dezenas a várias centenas de megabytes, dependendo do fornecedor e dos campos incluídos) fica ao lado da sua aplicação. As consultas são leituras em memória que normalmente terminam em microssegundos, não há salto de rede por requisição e nenhum endereço sai da sua infraestrutura. Esse último ponto importa se a sua revisão de privacidade trata o IP de um visitante como dado pessoal que não deve ser compartilhado com terceiros.
O custo está em tudo o que cerca o arquivo. Alguém precisa baixar novas versões em um cronograma, validá-las, distribuí-las a cada servidor ou contêiner e lidar com o caso em que um deploy envia uma cópia desatualizada. O licenciamento varia conforme o provedor, e alguns bancos comerciais têm termos diferentes dos gratuitos, então leia-os antes de incorporar um arquivo a um produto. Um banco de dados também só responde ao que contém: se você quer sinalizadores de VPN, Tor ou abuso, eles vêm de arquivos ou serviços separados que você deve atualizar em sua própria cadência.
O que uma API de geolocalização de IP muda
Uma API transfere o pipeline de dados para o provedor. Você envia um endereço e recebe JSON estruturado, e os dados por trás são atualizados sem que você toque em um deploy. Para uma equipe pequena, isso elimina uma tarefa recorrente. Também facilita obter campos que seriam incômodos de distribuir como arquivo. Uma única chamada à consulta de IP do ipto retorna país, cidade, ASN, organização e código de moeda, além dos sinalizadores is_vpn, is_tor, is_abuser, is_datacenter e bogon com bogon_type.
Os compromissos são reais. Cada consulta acrescenta um ciclo de ida e volta pela rede, então a latência é medida em milissegundos, e não em microssegundos. Você depende da disponibilidade e dos limites de taxa do provedor, o que significa que precisa de timeouts, de um fallback e, idealmente, de um cache. E o endereço é enviado a um terceiro, o que precisa constar na sua documentação de privacidade. O ipto é gratuito, sem cadastro, e permite 1.000 requisições gratuitas por dia, o suficiente para prototipar ou operar um serviço de baixo volume, embora cargas de trabalho de alto tráfego devam se planejar em torno desse limite.
Atualidade não é o mesmo que precisão
As pessoas costumam supor que uma API é mais precisa por ser "ao vivo". Na maior parte, ela é apenas mais atual. O problema de fundo, mapear um endereço a um lugar, é o mesmo nos dois casos, e os resultados em nível de cidade são mais fracos que os de país em ambos os modelos, especialmente em conexões móveis e residenciais. O que difere é o quão desatualizados os dados podem ficar. Um arquivo autohospedado tem a idade da sua última atualização bem-sucedida. Uma API tem a idade do ciclo de atualização do provedor: no ipto, os feeds de ameaças (VPN, Tor, abuso) são atualizados a cada 6 horas, e os conjuntos de dados de IP e ASN, diariamente. Nenhum dos dois é em tempo real, e um endpoint de VPN novo em folha não será sinalizado até que um feed o capte.
Uma regra de decisão prática
- Volume muito alto ou orçamento de latência rígido: um banco de dados local geralmente vence, porque o custo de rede por chamada e os limites de taxa desaparecem.
- Regras estritas de residência de dados: mantenha as consultas locais, já que nenhum endereço é transmitido a lugar algum.
- Equipe pequena, tráfego moderado, necessidade de sinais de risco: uma API costuma ser mais barata em tempo de engenharia, porque feeds, dados de ASN e reputação já estão montados.
- Meio-termo: use uma API com um cache local indexado por endereço (ou por faixa de rede) e um tempo de vida razoável. Muitas aplicações veem os mesmos endereços repetidamente, então o cache absorve a maior parte do tráfego.
Você também pode combinar os modelos: um arquivo local em nível de país para o caminho crítico, e uma chamada de API apenas quando uma requisição parece incomum e você quer contexto de ASN, VPN ou abuso. O verificador de VPN, Tor e proxy mostra exatamente como esses sinalizadores de risco se parecem para um determinado endereço, e a consulta de ASN mostra o proprietário da rede por trás dele. O formato da requisição e da resposta é descrito na documentação da API.
Experimente antes de decidir
A maneira mais barata de avaliar o modelo de API é passar amostras do seu tráfego real por ele e comparar. Cole alguns endereços dos seus logs no verificador de abuso de IP, ou chame o endpoint de consulta a partir de um script e meça o tempo de ida e volta no local onde seus servidores realmente rodam. Meça sua própria latência e taxa de acerto em vez de confiar em uma afirmação genérica, e decida se as diferenças restantes justificam operar um pipeline de dados por conta própria.