Quand ton outil de recherche semble lire dans tes pensées

Tu sais ce moment où tu tapes trois lettres et le résultat apparaît avant même que tu aies fini ? Pas de magie. Juste de l'ingénierie. Et croyez-moi, c'est fascinant quand on bosse avec 240 millions de noms de domaine.

Pourquoi chaque milliseconde compte

Quand quelqu'un tape dans une barre de recherche, il veut des résultats. Maintenant. Des études ont montré que le seuil magique, c'est 0,1 seconde. En dessous, l'interface donne l'impression de réagir instantanément. Au-dessus, çarame.

Pour un outil d'inspection de domaine comme Wirewiki, l'autocomplete, c'est la porte d'entrée. Chaque milliseconde compte. L'utilisateur doit avoir l'impression que l'outil lit dans ses pensées, pas qu'il attend un serveur quelque part.

L'astuce du prefetching

Voici le plus beau dans l'histoire : le secret n'est pas de rendre l'API plus rapide (même si ça aide). Non, le vrai gain, c'est de voler du temps sur le processus de saisie lui-même.

Quand l'utilisateur appuie sur une touche (keyDown), tu précharges les suggestions pour ce qu'il tape ET pour le caractère suivant probable. Quand il relâche (keyUp), t'affiches ce qui est prêt. Résultat : ton budget temps, c'est plus la latence de l'API. C'est la durée entre deux frappes.

Sur un écran 60Hz, t'as 16,7ms par image. Le calcul donne environ 121ms pour les dactylos rapides au p99. C'est ta fenêtre. Prépare les résultats avant la fin de la deuxième frappe, et pour l'utilisateur, c'est instantané.

Penser la vitesse à l'échelle

L'API doit gérer 240 millions de domaines sans broncher. Le truc malin, c'est de traiter différemment les domaines populaires et le reste :

La tête : Les domaines star vivent dans un trie stocké entièrement en mémoire. Les recherches par préfixe, c'est juste des promenades de pointeurs — rapide et prévisible. Les 8 premières suggestions pour chaque préfixe possible sont précalculées. Dans le pire des cas ? Complexité proportionnelle à la longueur de la saisie. Donc minuscule.

La queue : Tout le reste vit sur SSD avec un index en mémoire. Les domaines sont triés, delta-compressés, organisés en blocs de taille fixe. Un petit annuaire en mémoire permet la recherche binaire. Les 240M de domaines occupent environ 2,5 Go. Le système d'exploitation gère automatiquement le caching des pages chaudes.

Les deux structures ont des entrées bornées. Ni le nombre de domaines ni la longueur des requêtes ne croissent infiniment. La complexité effective devient donc du O(1) pratique. La latence p99 reste basse, toujours.

Les chiffres parlent

Les tests de charge ont révélé quelque chose d'intéressant. L'API répond en dessous de 2ms la plupart du temps. Même sous pression à 1 600 requêtes par seconde, Nginx + l'API tient 15ms au p99. Pas mal du tout.

Mais voila où la réalité frappe : le réseau. En pratique, la latence bout en bout, c'est le temps d'aller-retour du navigateur à Cloudflare jusqu'au serveur, plus environ 10ms de surcharge. Pour les utilisateurs dans la même région que le serveur ? T'es dans les temps. Pour les autres ? C'est là que ça se complique.

L'astérisque

p99 0ms* signifie que 99% des requêtes reviennent avant que l'utilisateur finisse sa frappe, s'il est proche du serveur. Ajoute 100-200ms de latence transatlantique, et soudain t'es hors budget.

La solution ? Des serveurs géo-distribués avec load balancing. Mais pour un side project, ça fait beaucoup d'infrastructure à maintenir. Parfois, "suffisamment bon" c'est vraiment suffisant — surtout quand tes utilisateurs cibles sont des développeurs européens qui vérifient des domaines.

Ce que ça veut dire pour ton prochain projet

Il y a une leçon qui dépasse largement les recherches de domaine : prefetch intelligemment. Si tu sais ce que les utilisateurs vont demander ensuite, va le chercher avant qu'ils le demandent. Laisse l'UI réagir à ce qui est prêt plutôt que d'attendre la certitude.

La deuxième leçon, c'est le choix des structures de données. Un trie pour les données chaudes, une structure triée bien indexée pour le reste. Pas besoin de garder 240 millions d'entrées en RAM si tu conçois tes patterns d'accès autour de ce qui est réellement susceptible d'être demandé.

Enfin, mesure ton vrai budget. Ici, c'était deux frappes plus l'intervalle. Quel est le tien ? Trouve-le, оптимизируй pour lui, et arrête de оптимизировать au-delà.

Le résultat donne l'impression d'être de la magie. Mais ça commence par comprendre exactement combien de temps t'as vraiment.