Autocomplete em 0 ms para 240 milhões de domínios
Aprofundamento CEVIU
Aprofundamento
O autocomplete de 0 ms em Wirewiki não é mágica, é engenharia de baixo nível aplicada com rigor a um problema clássico: latência percebida. O segredo está na combinação de três camadas técnicas sincronizadas: prefetching no lado do cliente (disparado em keydown, não em input), estrutura de dados otimizada (trie em memória para os 1 milhão de domínios mais populares + índice em bloco delta-comprimido para os 240 milhões restantes) e limitação explícita do escopo: só 38 caracteres válidos, resposta máxima de 8 sugestões, payload final ~2,5 kB comprimido.
A arquitetura ignora abordagens genéricas de busca full-text ou embeddings, aqui, cada prefixo digitado aciona uma travessia determinística em estruturas com complexidade efetivamente O(1). Isso permite que o servidor responda em até 15 ms (p99) mesmo sob 1.6k req/s, mas o verdadeiro ganho vem da antecipação: o resultado está pronto antes do keyup, porque o fetch já foi feito durante a pressão da tecla anterior. É UX orientado a frame, não a requisição.
Por que isso importa
Esse projeto é um case study raro de otimização *end-to-end* com foco em performance percebida, não em métricas de servidor, mas no tempo entre intenção do usuário (começar a digitar) e feedback visual (sugestões renderizadas). Para devs, mostra que ainda vale a pena dominar estruturas clássicas (trie, binary search em blocos ordenados) quando o domínio é bem delimitado. Também expõe uma verdade prática: depois de 2, 3 ms no backend, o gargalo real é a rede, e nesse cenário, prefetching inteligente supera qualquer otimização de código-fonte. Não é IA, não é serverless, não é edge function: é algoritmo certo, no lugar certo, com timing ajustado ao comportamento humano.
Perguntas frequentes
Como é possível ter '0 ms' de latência se há sempre tempo de rede?
O '0 ms' refere-se à latência percebida: o resultado já está disponível no cliente no exato momento em que o usuário solta a tecla. Isso acontece porque a requisição é disparada durante a pressão da tecla anterior, aproveitando o intervalo entre keystrokes, um orçamento temporal invisível para o usuário.
Por que usar trie + índice em bloco, e não um banco de dados relacional ou Elasticsearch?
Porque o problema é estritamente de prefix search em um conjunto estático e ordenado. Um trie em memória resolve buscas por prefixo em O(n), onde n é o número de caracteres digitados, muito mais rápido que qualquer consulta SQL ou análise de texto. Já o índice em bloco evita carregar 2,5 GB na RAM, mantendo acesso rápido via mmap e cache do SO.
O que impede esse sistema de escalar globalmente sem múltiplos servidores?
A latência de rede. O orçamento de 121 ms (p99) é suficiente para Europa, mas usuários nos EUA adicionam 100, 200 ms de round-trip. Como o backend já responde em ~15 ms, não adianta otimizar mais o código, o limite é físico. Geo-distribuição resolveria, mas o autor optou por manter simplicidade, já que o uso é nicho e não comercial.
Fontes
- ruurtjan.comfonte original
- Categoria
- CEVIU Web Dev
- Publicado
- 23 de junho de 2026
- Editoria
- CEVIU Web Dev
