Светкавично дописване: Изкуството на мигновените домейн предложения

Светкавично дописване: Изкуството на мигновените домейн предложения

Юни 25, 2026 web performance dns api design ux optimization developer tools

Как направих търсенето на домейни мигновено (и защо 240 милиона имена не са проблем)

Случвало ли ти се е да започнеш да пишеш и autocomplete-ът вече да е готов с предложенията? Не е магия — това е добро инженерство. И става наистина интересно, когато работиш с 240 милиона домейна.

Защо скоростта е по-важна, отколкото си мислиш

Потребителите очакват резултати незабавно. Според Nielsen Norman Group, прагът е 0.1 секунди — след това интерфейсът започва да се усеща бавен и прекъсва потока на работа.

За инструмент като Wirewiki, autocomplete-ът е основната входна точка. Всяка милисекунда има значение, когато проверяваш DNS записи. Потребителят трябва да чувства, че инструментът чете мислите му, не че чака отговор от сървъра.

Трика с предварителното зареждане

Ето къде идва хитростта: не става въпрос да направиш API-то по-бързо (макар че помага). Става въпрос да откраднеш време от самия процес на въвеждане.

Когато потребителят натисне клавиш (keyDown), ти зареждаш предложения за това, което въвежда, плюс следващата вероятна буква. Когато пусне клавиша (keyUp), рендерираш каквото е готово. Така бюджетът ти не е латенцията на API-то — а продължителността на две натискания на клавиши плюс паузата между тях.

На 60Hz дисплей имаш 16.7ms на кадър. За бързи пишещи потребители на p99 това прави около 121ms. Това е твоят прозорец. Подготви резултатите преди второто натискане да е приключило и за потребителя всичко изглежда мигновено.

Дизайн за скорост в мащаб

API-то трябва да се справя с 240 милиона домейна без проблеми. Хитрото тук е да третираш популярните домейни различно от дългата опашка:

Горещата част: Топ домейните живеят в character trie изцяло в паметта. Търсенето по префикс е просто обхождане на указатели — бързо и предвидимо. Топ 8 предложения за всеки възможен префикс са предварително изчислени. Най-лошият случай? O(дължина на въвеждане). Тоест минимално.

Студената част: Всичко останало е на SSD с памет-карта block index. Домейните са сортирани, delta-compressed и организирани в блокове с фиксиран размер, като малка in-memory директория поддържа binary search. 240M домейна заемат около 2.5GB, а операционната система автоматично кешира горещите страници.

И двете структури имат ограничени входни данни — броят на домейните и дължината на заявката не растат безкрайно. Това прави ефективната сложност практически O(1) и поддържа p99 латенцията стабилно ниска.

Числата не лъжат

Стресовите тестове показаха нещо интересно. Самото API отговаря на повечето заявки за под 2ms. Дори под натоварване при 1,600 заявки в секунда, Nginx плюс API-то се справя за 15ms на p99. Солидно.

Но тук идва реалността: мрежата. На практика крайната латенция е равна на round-trip time от браузъра през Cloudflare до сървъра, плюс около 10ms overhead. За потребители в същия регион като сървъра — всичко е наред. За всички останали? Там се появява звездичката.

Звездичката

p99 0ms* означава, че 99% от заявките връщат резултати преди потребителят да е приключил с натискането на клавиша, ако са близо до сървъра. Добави 100-200ms трансатлантическа латенция и изведнъж вече си над бюджета.

Решението биха били geo-distributed сървъри с load balancing. Но за страничен проект това е много инфраструктура за поддръжка. Понякога "достатъчно добро" наистина е достатъчно добро — особено когато целевите ти потребители са европейски разработчици, проверяващи домейни.

Какво означава това за следващия ти проект

Има урок тук, който важи далеч отвъд домейн търсенето: зареждай предварително умно. Ако знаеш какво потребителите може да потърсят след това, вземи го преди да са попитали. Нека UI реагира на това, което е готово, вместо да чака сигурност.

Вторият урок е за избора на структури от данни. Trie за горещи данни, добре индексирана сортирана структура за всичко останало. Не ти трябва да държиш 240 милиона елемента в RAM, ако дизайнираш достъпните модели около това, което реално ще се търси.

И накрая — измери реалния си бюджет. Тук това са две натискания на клавиши плюс пауза. Кое е твоят еквивалент? Намери го, оптимизирай към него и спри да оптимизираш отвъд него.

Резултатът се усеща като магия. Но започва с разбирането точно колко време всъщност имаш.

Read in other languages:

RU EL CS UZ TR SV FI RO PT PL NB NL HU IT FR ES DE DA ZH-HANS EN