Jak jsme udělali vyhledávání domén tak rychlé, že vypadá jako magie

Někdy napíšete pár písmen a návrhy se objeví dřív, než stihnete pustit klávesu. Žádné kouzlo – čistá inženýrství. A když pracujete s 240 miliony domén, je to pořádná výzva.

Proč rychlost není zbytečný luxus

Lidé očekávají okamžitou odezvu. Studie Nielsen Norman Group ukázala, že hranice pro "okamžitý" pocit je 0,1 sekundy. Cokoliv pomalejšího a interface začíná působit těžkopádně – narušuje ten příjemnýFLOW při procházení.

U nástroje na kontrolu domén jako Wirewiki je autocomplete hlavní vstupní bod. Každá milisekunda hraje roli. Uživatel by měl mít pocit, že nástroj čte jeho myšlenky, ne že čeká na server.

Trik s prefetchingem

Tady přichází ta krásná část: řešení není zrychlit API (i když to pomáhá). Je to o krádeži času samotnému procesu psaní.

Když uživatel stiskne klávesu (keyDown), začnete načítat návrhy pro to, co píše, plus pro další pravděpodobný znak. Když klávesu pustí (keyUp), zobrazíte co je připraveno. Váš časový rozpočet tedy není latence API – je to doba dvou stisknutí kláves plus mezera mezi nimi.

Na 60Hz displeji máte 16,7ms na jeden snímek. Pro rychlé pisáře na p99 to dává zhruba 121ms. Tolik máte k dispozici. Připravte výsledky před koncem druhého stisknutí a uživatel má dojem okamžité odezvy.

Architektura pro rychlost ve velkém měřítku

API musí zvládnout 240 milionů domén bez zadýchání. Chytrý přístup je rozdělit populární domény od "dlouhého ocasu":

Hlava: Nejpoužívanější domény bydlí v trie stromu celém v paměti. Hledání podle prefixu je jen procházení ukazatelů – rychlé a předvídatelné. Top 8 návrhů pro každý možný prefix je předpočítaných. nejhorší případ? O(délka vstupu). Což je v praxi zanedbatelné.

Ocas: Zbytek leží na SSD s memory-mapped indexem. Domény jsou seřazené, delta-komprimované a organizované do bloků pevné velikosti. Malý in-memory adresář umožňuje binary search. 240M domén zabírá asi 2,5GB a OS si cachuje aktivní stránky automaticky.

Obě struktury mají ohraničené vstupy – počet domén a délka dotazu nerostou neomezeně. To dělá efektivní komplexitu prakticky O(1) a p99 latenci stabilně nízkou.

Čísla mluví jasně

Zátěžové testy odhalily zajímavou věc. Samotné API odpovídá většinou pod 2ms. I při zátěži 1 600 requestů za sekundu reaguje Nginx s API za 15ms na p99. To není špatné.

Ale tady přichází realita: síť. V praxi je end-to-end latence rovna round-trip času z prohlížeče přes Cloudflare na váš server, plus zhruba 10ms režie. Pro uživatele ve stejné oblasti jako server jsme v rozpočtu. Pro ostatní? Tam je ten háček.

Ten háček

p99 0ms* znamená, že 99 % requestů vrátí výsledky před tím, než uživatel pustí klávesu – když je blízko serveru. Přidejte 100-200ms transatlantické latence a najednou překračujete rozpočet.

Řešení by byly geograficky distribuované servery s load balancingem. Ale pro side project je to spousta infrastruktury na údržbu. Někdy "dost dobré" opravdu stačí – obzvlášť když vaši cíloví uživatelé jsou evropští vývojáři kontrolující domény.

Co si odnést pro vaše další projekty

Lekce, která platí daleko za hranicemi doménových vyhledávání: prefetechujte chytře. Pokud víte, co uživatelé pravděpodobně budou chtít dál, načtěte to předtím, než se zeptají. Nechte UI reagovat na to, co je připraveno, místo čekání na jistotu.

Druhá lekce se týká výběru datových struktur. Trie pro horká data, dobře indexovaná seřazená struktura pro zbytek. Nemusíte držet 240 milionů položek v RAM, když navrhnete přístupové vzory kolem toho, co je skutečně pravděpodobně potřeba.

A nakonec – změřte si skutečný rozpočet. Tady to byly dva stisky kláves plus mezera. Co je váš ekvivalent? Najděte ho, optimalizujte k němu a přestaňte optimalizovat za ním.

Výsledek působí jako magie. Ale začíná to pochopením, kolik času vlastně máte.