Como fazer autocomplete parecer mágica (sem ser)

Você já reparou que quando digita algo, a sugestão aparece antes mesmo de terminar de apertar a tecla? Não é mágica — é engenharia. E é um problema fascinante quando você está lidando com 240 milhões de domínios.

Por que velocidade importa mais do que você imagina

Quando alguém digita numa caixa de busca, espera ver resultados na hora. O Nielsen Norman Group descobriu que 0,1 segundos é o limite para o usuário sentir que tudo aconteceu instantaneamente. Mais devagar que isso? A interface parece lenta — e isso quebra o fluxo.

Para uma ferramenta de inspeção de domínios como Wirewiki, o autocomplete é o ponto de entrada principal. Cada milissegundo conta quando você quer consultar registros DNS rápido. O usuário precisa sentir que a ferramenta está lendo sua mente, não esperando um servidor responder.

O Truque do Prefetch

Aqui está a parte interessante: o segredo não está em tornar a API mais rápida (embora isso ajude). Está em roubar tempo do próprio processo de digitação.

Quando o usuário pressiona uma tecla (keyDown), você já busca sugestões para o que ele está digitando e para o próximo caractere mais provável. Quando solta a tecla (keyUp), você mostra o que está pronto. Isso significa que seu orçamento de tempo não é a latência da API — é a duração de duas teclas pressionadas mais o intervalo entre elas.

Em uma tela de 60Hz, você tem 16,7ms por frame. O orçamento fica em torno de 121ms para digitadores rápidos no percentil 99. Esse é o seu limite. Prepare os resultados antes do fim do segundo pressionamento de tecla, e para o usuário, parece instantâneo.

Projetando para Velocidade em Escala

A API precisa lidar com 240 milhões de domínios sem se atrapalhar. A abordagem esperta aqui é tratar domínios populares de forma diferente da cauda longa:

A Cabeça: Domínios famosos ficam em um trie de caracteres armazenado inteiramente na memória. Buscas por prefixo são apenas caminhadas de ponteiros — rápido e previsível. As 8 principais sugestões para cada prefixo possível são pré-calculadas. Pior caso? O(tamanho da entrada). Isso é mínimo.

A Cauda: Tudo o resto fica em um SSD com um índice de blocos em memória. Domínios são ordenados, comprimidos por delta e organizados em blocos de tamanho fixo com um pequeno diretório em memória para busca binária. Os 240M de domínios ocupam cerca de 2,5GB, e o sistema operacional faz o caching das páginas mais acessadas automaticamente.

Ambas estruturas têm entradas limitadas — o número de domínios e o tamanho da consulta não crescem indefinidamente. Isso faz a complexidade efetiva ser praticamente O(1), mantendo a latência no p99 consistentemente baixa.

Os Números Não Mentem

Testes de stress revelaram algo interessante. A API em si responde a maioria das requisições em menos de 2ms. Mesmo sob carga de 1.600 requisições por segundo, Nginx mais a API responde em 15ms no p99. Bem sólido.

Mas aqui é onde a realidade intervém: a rede. Na prática, a latência ponta-a-ponta é igual ao tempo de ida e volta do navegador até seu servidor, mais cerca de 10ms de overhead. Para usuários na mesma região do servidor, você está dentro do orçamento. Para todos os outros? É aí que aparece o asterisco.

O Asterisco

p99 0ms* significa que 99% das requisições retornam resultados antes do usuário terminar de pressionar a tecla, assumindo que ele está perto do servidor. Adicione 100-200ms de latência transatlântica, e de repente você está fora do orçamento.

A solução seria servidores distribuídos geograficamente com balanceamento de carga. Mas para um projeto paralelo, é muita infraestrutura para manter. Às vezes "suficientemente bom" realmente é suficiente — especialmente quando seus usuários-alvo são desenvolvedores europeus verificando domínios.

O Que Isso Significa Para Seu Próximo Projeto

Existe uma lição aqui que vai muito além de buscas de domínio: faça prefetch de forma inteligente. Se você sabe o que os usuários podem pedir a seguir, busque antes que eles peçam. Deixe a interface reagir ao que está pronto em vez de esperar por certeza.

A segunda lição é sobre escolha de estrutura de dados. Um trie para dados quentes, uma estrutura ordenada bem indexada para tudo mais. Você não precisa manter 240 milhões de itens na RAM se projetar seus padrões de acesso em torno do que realmente tende a ser solicitado.

Por fim, meça seu orçamento real. Neste caso, dois pressionamentos de tecla mais um intervalo. Qual é o seu equivalente? Encontre-o, otimize para ele, e pare de otimizar além dele.

O resultado parece mágico. Mas começa entendendo exatamente quanto tempo você realmente tem.