Hvorfor din domæne-søgning føles som telekinese

Har du nogensinde oplevet, at en autoforslag dukkede op, før du overhovedet var færdig med at trykke på tasten? Det er ikke magi. Det er hardcore engineering. Og det er et fascinerende problem, når man arbejder med 240 millioner domænenavne.

Hastighed betyder mere, end du tror

Brugere forventer øjeblikkelige resultater, når de skriver i et søgefelt. Nielsen Norman Group fastslog, at 0,1 sekunder er grænsen for, at folk føler, at ting sker med det samme. Alt, der er langsommere, føles trægt og bryder flowet.

For et domæne-inspektionsværktøj som Wirewiki er autoforslagene den primære indgang. Hvert millisekund tæller, når du vil slå DNS-records op hurtigt. Brugerne skal føle, at værktøjet læser deres tanker – ikke venter på en server.

Trikset med at stjæle tid

Det smarte ved dette handler ikke om at gøre API'en hurtigere (selvom det hjælper). Det handler om at stjæle tid fra selve indtastningsprocessen.

Når en bruger trykker på en tast, prefetcher du forslag til det, de skriver – plus det næste sandsynlige tegn. Når de slipper tasten, render du det, der allerede er klar. Det betyder, at din tidsbudget ikke er API-latensen – det er varigheden af to tastetryk plus pausen mellem dem.

På en 60Hz skærm har du 16,7ms per frame. Budgettet ender på omkring 121ms for hurtige skrivere ved p99. Det er dit vindue. Få resultaterne klar, før det andet tastetryk er slut, og for brugeren føles det øjeblikkeligt.

Design for hastighed i stor skala

API'en skal håndtere 240 millioner domænenavne uden at bryde sammen. Løsningen er at behandle populære domæner forskelligt fra den lange hale:

Den varme ende: Topdomæner lever i en karakter-trie gemt direkte i hukommelsen. Prefix-opslag er bare pointer-gåture – hurtige og forudsigelige. De otte bedste forslag for hvert mulige prefix er præberegnet. Værste fald? O(længden af input). Det er ubetydeligt.

Den kolde hale: Alt andet ligger på en SSD med et memory-mapped block-index. Domænerne er sorteret, delta-komprimeret og organiseret i fast størrelse blocks med et lille in-memory directory til binary search. De 240 millioner domæner fylder omkring 2,5GB, og operativsystemet håndterer automatisk caching af hyppigt brugte sider.

Begge strukturer har afgrænsede inputs – antallet af domæner og forespørgselslængden vokser ikke vilkårligt. Det gør den effektive kompleksitet praktisk talt O(1), så p99-latensen forbliver konsistent lav.

Tallene lyver ikke

Belastningstest afslørede noget interessant. Selve API'en svarer på de fleste forespørgsler på under 2ms. Selv under belastning ved 1.600 requests per sekund svarer Nginx plus API'en på 15ms ved p99. Ret solidt.

Men her kommer virkeligheden ind i billedet: netværket. I praksis er end-to-end-latensen lig med round-trip-tiden fra browser gennem Cloudflare til din server plus omkring 10ms overhead. For brugere i samme region som serveren er du inden for budgettet. For alle andre? Der dukker stjernen op.

Stjernen

p99 0ms* betyder, at 99% af forespørgslerne returnerer resultater, før brugeren er færdig med at trykke på tasten – forudsat de er tæt på serveren. Tilføj 100-200ms transatlantisk latency, og pludselig er du over budget.

Løsningen ville være geo-distribuerede servere med load balancing. Men for et sideprojekt er det en masse infrastruktur at vedligeholde. Nogle gange er "godt nok" virkelig godt nok – især når dine målbrugere er europæiske udviklere, der tjekker domæner.

Hvad dette betyder for dit næste projekt

Der er en læring her, der rækker langt ud over domæneopslag: prefetch klogt. Hvis du ved, hvad brugere sandsynligvis vil spørge om næste gang, så hent det, før de spørger. Lad brugergrænsefladen reagere på det, der er klar, i stedet for at vente på sikkerhed.

Den anden læring handler om valg af datastruktur. En trie til varme data, et velindexeret sorteret system til alt andet. Du behøver ikke holde 240 millioner elementer i RAM, hvis du designer dine adgangsmønstre omkring det, der faktisk sandsynligvis bliver spurgt om.

Endelig: mål dit faktiske budget. I dette tilfælde: to tastetryk plus en pause. Hvad er dit equivalent? Find det, optimér til det, og stop med at optimere ud over det.

Resultatet føles som magi. Men det starter med at forstå præcis, hvor meget tid du faktisk har.