Come ho reso istantanea la ricerca domini: il trucco del prefetch

Hai mai notato come certi suggerimenti appaiano prima che tu finisca di digitare? Non è magia. È pura ingegneria. E diventa un problema affascinante quando lavori con 240 milioni di domini.

Perché la velocità conta più di quanto pensi

Gli utenti si aspettano risultati immediati. Nielsen Norman Group ha stabilito che 0,1 secondi è la soglia oltre la quale l'interfaccia sembra lenta. Peggio: rompe il flusso di esplorazione.

Per uno strumento come Wirewiki, l'autocomplete è il punto d'ingresso principale. Ogni millisecondo conta quando devi controllare DNS records in fretta. L'utente deve pensare che il tool gli legga nel pensiero, non che aspetti un server.

Il trucco del prefetching

Ecco la parte interessante: il segreto non sta nel rendere l'API più veloce (anche se aiuta). Sta nel "rubare" tempo al processo di digitazione stesso.

Quando l'utente preme un tasto (keyDown), tu anticipi i suggerimenti per quello che sta scrivendo più il carattere successivo più probabile. Quando rilascia il tasto (keyUp), mostri quello che è già pronto.

Il budget non è più la latenza dell'API. È la durata di due pressioni di tasto più il gap tra di esse.

Su un display 60Hz hai 16,7ms per frame. Per i dattilografi veloci al p99, il budget arriva a circa 121ms. Questa è la tua finestra. Prepara i risultati prima che finisca la seconda pressione, e per l'utente sembrerà istantaneo.

Progettare per la velocità su scala

L'API deve gestire 240 milioni di domini senza sudare. Il trucco è trattare diversamente i domini popolari dal long tail.

La testa: I domini più richiesti vivono in un trie in memoria. Le ricerche per prefisso sono semplici passeggiate tra puntatori—veloci e prevedibili. Le top 8 suggerimenti per ogni prefisso sono precalcolate. Caso peggiore? O(length of input). Roba da niente.

La coda: Tutto il resto sta su SSD con un block index memory-mapped. I domini sono ordinati, delta-compressi, organizzati in blocchi di dimensione fissa. Una piccola directory in memoria permette la binary search.

I 240M di domini occupano circa 2,5GB. Il sistema operativo gestisce il caching delle pagine calde automaticamente.

Entrambe le strutture hanno input limitati—il numero di domini e la lunghezza delle query non crescono all'infinito. Questo rende la complessità effettiva praticamente O(1), mantenendo la latenza p99 costantemente bassa.

I numeri parlano chiaro

I test di stress hanno rivelato qualcosa di interessante. L'API risponde alla maggior parte delle richieste in meno di 2ms. Sotto carico, a 1.600 richieste al secondo, Nginx più l'API risponde in 15ms al p99. Niente male.

Ma ecco dove la realtà ci mette lo zampino: la rete. In pratica, la latenza end-to-end è il tempo di andata e ritorno dal browser attraverso Cloudflare fino al server, più circa 10ms di overhead. Per gli utenti nella stessa regione del server, sei dentro budget. Per tutti gli altri? Lì emerge l'asterisco.

L'asterisco

p99 0ms* significa che il 99% delle richieste restituisce risultati prima che l'utente finisca di premere il tasto, ammesso che sia vicino al server. Aggiungi 100-200ms di latenza transatlantica, e improvvisamente sei fuori budget.

La soluzione sarebbero server geo-distribuiti con load balancing. Ma per un side project, è un sacco di infrastruttura da mantenere. A volte "buono abbastanza" è davvero sufficiente—soprattutto quando i tuoi utenti target sono sviluppatori europei che controllano domini.

Cosa significa questo per il tuo prossimo progetto

C'è una lezione che vale ben oltre le ricerche di domini: prefetch in modo intelligente. Se sai cosa potrebbero chiedere gli utenti dopo, recuperalo prima che lo chiedano. Fai reagire l'interfaccia a quello che è pronto, invece di aspettare la certezza.

La seconda lezione riguarda la scelta delle strutture dati. Un trie per i dati caldi, una struttura ordinata ben indicizzata per tutto il resto. Non devi tenere 240 milioni di elementi in RAM se progetti i pattern di accesso attorno a quello che è davvero probabile che venga richiesto.

Infine, misura il tuo budget reale. In questo caso: due pressioni di tasto più un gap. Qual è il tuo equivalente? Trovalo, ottimizza per quello, e fermati oltre.

Il risultato sembra magia. Ma inizia con il capire esattamente quanto tempo hai davvero a disposizione.