Hemmeligheten bak lynraske domeneforslag
Slik føles verktøyet som å lese tankene dine
Har du lagt merke til hvordan forslagene dukker opp før du har sluppet tasten? Det er ikke magi. Det er ingeniørkunst.
Hvorfor millisekunder betyr noe
Brukere forventer umiddelbare resultater. Forskning fra Nielsen Norman Group viser at 0,1 sekunder er grensen for at noe føles øyeblikkelig. Alt tregere enn det? Da oppleves grensesnittet som treigt.
For et DNS-verktøy som Wirewiki er autocomplete inngangspunktet. Hvert millisekund teller. Brukeren skal føle at verktøyet leser tankene, ikke venter på en server.
Trikset med prefetching
Her kommer den smarte delen: Problemet løses ikke bare ved å gjøre API-et raskere. Løsningen er å stjele tid fra selve inntastingen.
Når brukeren trykker ned en tast (keyDown), henter du forslag for det som skrives plus Neste sannsynlige tegn. Når tasten slippes (keyUp), viser du det som allerede er klart. Tidsbudsjettet ditt blir da ikke API-latensen — det er varigheten av to tastetrykk pluss gapet mellom dem.
På en 60Hz skjerm har du 16,7 millisekunder per bilde. Regner du på det, ender du opp med cirka 121 millisekunder for raske skribenter ved p99. Det er vinduet ditt. Få resultatene klare før det andre tastetrykket er ferdig, og for brukeren føles alt øyeblikkelig.
Arkitektur for hastighet i stor skala
API-et må håndtere 240 millioner domenenavn uten å bry en sweat. Trikset er å behandle populære domener annerledes enn den lange halen:
Toppen: De mest populære domenene lever i en karakter-trie fullstendig lagret i minnet. Prefiks-oppslag er bare pointer-gange — raskt og forutsigbart. De åtte beste forslagene for ethvert prefiks er forhåndsberegnet. Verste fall? O(lengde på input). Altså minimalt.
Halen: Alt annet ligger på SSD med en memory-mapped blokkindeks. Domenene er sortert, delta-komprimert og organisert i fast størrelse med en liten in-memory katalog for binærsøk. 240 millionene domenene tar omtrent 2,5 GB, og operativsystemet håndterer caching av varme sider automatisk.
Begge strukturene har avgrensede input — antall domener og spørringslengde vokser ikke ubestemt. Det gjør den effektive kompleksiteten praktisk talt O(1), og p99-latensen stabilt lav.
Tallene lyver ikke
Stresstesting avslørte noe interessant. Selve API-et svarer på de fleste forespørsler på under 2 millisekunder. Selv under last ved 1 600 forespørsler per sekund, svarer Nginx pluss API på 15 millisekunder ved p99. Ikke verst.
Men her griper virkeligheten inn: nettverket. I praksis er end-to-end-latensen lik round-trip-tiden fra nettleser gjennom Cloudflare til serveren, pluss omtrent 10 millisekunder overhead. For brukere i samme region som serveren? Da er du innenfor budsjettet. For alle andre? Der kommer stjernen.
Stjernen
p99 0ms* betyr at 99 % av forespørslene returnerer resultater før brukeren er ferdig med tastetrykket, forutsatt at de er nær serveren. Legg til 100–200 millisekunder med transatlantisk latency, og plutselig er du over budsjettet.
Løsningen hadde vært geografisk distribuerte servere med lastbalansering. Men for et sideprosjekt? Det er mye infrastruktur å drifte. Noen ganger er godt nok virkelig godt nok — spesielt når målgruppen er europeiske utviklere som sjekker domener.
Lærdommen for ditt neste prosjekt
Det finnes en leksjon her som rekker langt utover domenetoppslag: prefetche smart. Hvis du vet hva brukerne sannsynligvis spør om neste, hent det før de spør. La grensesnittet reagere på det som er klart i stedet for å vente på sikkerhet.
Den andre leksjonen handler om datastrukturvalg. En trie for varme data, en godt indeksert sortert struktur for alt annet. Du trenger ikke holde 240 millioner elementer i RAM hvis du designer tilgangsmønsteret rundt hva som faktisk blir spurt om.
Til slutt: mål det faktiske budsjettet. I dette tilfellet to tastetrykk pluss et gap. Hva er ditt motsvar? Finn det, optimaliser mot det, og slutt å optimalisere forbi det.
Resultatet føles som magi. Men det starter med å forstå nøyaktig hvor mye tid du faktisk har.