CEVIU Logo
Voltar

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

Avalie este artigo:
Compartilhar:
Categoria
CEVIU Web Dev
Publicado
23 de junho de 2026
Editoria
CEVIU Web Dev

Quer receber mais sobre CEVIU Web Dev?

Conteúdo curado diariamente, direto no seu e-mail.

Conteúdo curado diariamenteDiversas categoriasCancele quando quiser