Cum am făcut autocomplete-ul să se simtă instantaneu pentru 240 de milioane de domenii

Tipărești primele litere și sugestia apare înainte să termini de apăsat tasta? Nu e magie—e inginerie. Și e o problemă fascinantă când lucrezi cu 240 de milioane de domenii.

De ce contează atât de mult viteza

Când utilizatorii scriu într-un câmp de căutare, vor rezultate imediat. Nielsen Norman Group a stabilit că 0.1 secunde e pragul de la care utilizatorii simt că totul se întâmplă instantaneu. Orice mai lent face interfața să pară lentă—și întrerupe experiența de explorare.

Pentru un tool de inspectare domenii precum Wirewiki, autocomplete-ul e punctul principal de intrare. Fiecare milisecundă contează când vrei să verifici rapid înregistrările DNS. Utilizatorii trebuie să simtă că tool-ul le citește gândurile, nu că așteaptă după un server.

Trucul cu prefetching-ul

Partea interesantă: insight-ul principal nu e să faci API-ul mai rapid (deși asta ajută). E să furi timp din procesul本身 de tastare.

Când un utilizator apasă o tastă (keyDown), faci prefetch pentru ceea ce tastează plus următorul caracter probabil. Când eliberează tasta (keyUp), afișezi ce e deja gata. Astfel, bugetul tău de timp nu mai e latența API-ului—ci durata a două taste și pauza dintre ele.

Pe un display de 60Hz, ai 16.7ms per frame. Bugetul se traduce în aproximativ 121ms pentru tastezii rapizi la p99. Asta e fereastra ta. Pregătește rezultatele înainte să se termine a doua apăsare, iar pentru utilizator va părea instantaneu.

Arhitectura pentru viteză la scară

API-ul trebuie să gestioneze 240 de milioane de domenii fără să transpire. Abordarea inteligentă e să tratezi diferit domeniile populare de restul:

Capul: Domeniile top stau într-un character trie, în întregime în memorie. Căutările de prefix sunt doar deplasări prin pointeri—rapide și previzibile. Top 8 sugestii pentru fiecare prefix posibil sunt precalculate. Cazul cel mai rău? O(lungimea input-ului). Adică foarte mic.

Coada: Restul stă pe SSD cu un block index memory-mapped. Domeniile sunt sortate, delta-comprimate și organizate în blocuri de dimensiune fixă, cu un mic director în memorie pentru căutare binară. Cele 240M de domenii ocupă aproximativ 2.5GB, iar OS-ul se ocupă automat de caching-ul paginilor frecvent accesate.

Ambele structuri au input bound—numărul de domenii și lungimea query-ului nu cresc nemărginit. Asta face complexitatea efectivă practic O(1), menținând latența p99 constant de scăzută.

Numerele nu mint

Testele de stres au scos la iveală ceva interesant. API-ul răspunde la majoritatea request-urilor în sub 2ms. Chiar și sub load la 1,600 de cereri pe secundă, Nginx plus API-ul răspunde în 15ms la p99. Destul de solid.

Dar iată unde realitatea intervine: rețeaua. În practică, latența end-to-end e egală cu round-trip time-ul de la browser prin Cloudflare până la server, plus aproximativ 10ms overhead. Pentru utilizatorii din aceeași regiune cu serverul, ești în buget. Pentru restul? Aici apare asteriscul.

Asteriscul

p99 0ms* înseamnă că 99% din cereri returnează rezultate înainte să se termine apăsarea tastei, presupunând că utilizatorul e aproape de server. Adaugă 100-200ms latență transatlantică, și brusc ai depășit bugetul.

Soluția ar fi servere geo-distribuite cu load balancing. Dar pentru un side project, e multă infrastructură de menținut. Uneori "destul de bun" chiar e destul de bun—mai ales când utilizatorii țintă sunt dezvoltatori europeni care verifică domenii.

Ce înseamnă asta pentru proiectul tău

E o lecție care se aplică dincolo de căutările de domenii: prefetch inteligent. Dacă știi ce ar putea cere utilizatorii în continuare, adu-le datele înainte să întrebe. Lasă UI-ul să reacționeze la ce e gata, nu să astepte certitudinea.

A doua lecție ține de alegerea structurilor de date. Un trie pentru datele fierbinți, o structură sortată bine indexată pentru rest. Nu trebuie să ții 240 de milioane de item-uri în RAM dacă îți proiectezi pattern-urile de acces în jurul a ce e probabil să fie cerut.

În final, măsoară-ți bugetul real. În acest caz, două taste plus pauza dintre ele. Care e echivalentul tău? Găsește-l, optimizează pentru el, și oprește-te din optimizat dincolo de el.

Rezultatul se simte ca magia. Dar începe cu înțelegerea exactă a cât timp ai la dispoziție.