Cuando tu herramienta parece leer tu mente: el arte del autocomplete ultrarrápido

¿Alguna vez has escrito algo y la sugerencia apareció antes de que terminaras de presionar la tecla? No es magia — es ingeniería. Y cuando trabajas con 240 millones de dominios, se vuelve un problema bastante interesante.

Por qué la velocidad importa más de lo que crees

Cuando alguien escribe en un buscador, espera resultados al instante. Nielsen Norman Group estableció que 0.1 segundos es el umbral para que los usuarios sientan que sus acciones son instantáneas. Si es más lento, la interfaz se siente torpe y interrumpe el flujo de exploración.

Para una herramienta de inspección de dominios como Wirewiki, el autocomplete es la puerta de entrada principal. Cada milisegundo cuenta cuando quieres consultar registros DNS rápidamente. Los usuarios deberían sentir que la herramienta les lee la mente, no que está esperando al servidor.

El truco del prefetching

Aquí viene lo interesante: el secreto no está en hacer más rápida la API (aunque eso ayuda). Está en robarle tiempo al proceso de escritura mismo.

Cuando el usuario presiona una tecla, haces prefetch de las sugerencias para lo que están escribiendo más el siguiente carácter probable. Cuando sueltan la tecla, renderizas lo que ya esté listo. Esto significa que tu presupuesto de tiempo no es la latencia de la API — es la duración de dos tecleos más el espacio entre ellos.

En una pantalla a 60Hz, tienes 16.7ms por frame. El presupuesto se traduce en unos 121ms para tecleadores rápidos en el percentil 99. Ese es tu margen. Si tienes los resultados listos antes de que termine el segundo tecleo, para el usuario se siente instantáneo.

Diseñando para velocidad a escala

La API necesita manejar 240 millones de dominios sin sudar. El truco está en tratar los dominios populares de forma diferente a los que están en la cola larga:

La cabeza: Los dominios más consultados viven en un trie de caracteres guardado completamente en memoria. Las búsquedas por prefijo son solo caminatas de punteros — rápidas y predecibles. Las 8 mejores sugerencias para cada prefijo posible están precalculadas. Peor caso? O(longitud del input). Eso es diminuto.

La cola: Todo lo demás vive en un SSD con un índice de bloques memory-mapped. Los dominios están ordenados, delta-comprimidos y organizados en bloques de tamaño fijo con un pequeño directorio en memoria para búsqueda binaria. Los 240M de dominios ocupan unos 2.5GB, y el sistema operativo maneja el caché de páginas frecuentes automáticamente.

Ambas estructuras tienen entradas acotadas — el número de dominios y el largo de las consultas no crecen sin límites. Esto hace que la complejidad efectiva sea prácticamente O(1), manteniendo la latencia del p99 consistentemente baja.

Los números no mienten

Las pruebas de estrés revelaron algo interesante. La API responde la mayoría de solicitudes en menos de 2ms. Incluso bajo carga a 1,600 solicitudes por segundo, Nginx más la API responde en 15ms al p99. Bastante sólido.

Pero aquí es donde entra la realidad: la red. En la práctica, la latencia end-to-end es igual al tiempo de ida y vuelta desde el navegador, pasando por Cloudflare, hasta tu servidor, más unos 10ms de overhead. Para usuarios en la misma región que el servidor, estás dentro del presupuesto. ¿Para los demás? Ahí aparece el asterisco.

El asterisco

p99 0ms* significa que el 99% de las solicitudes devuelven resultados antes de que el usuario termine de presionar la tecla, asumiendo que están cerca del servidor. Agrega 100-200ms de latencia transatlántica, y de repente te sales del presupuesto.

La solución serían servidores geo-distribuidos con balanceo de carga. Pero para un proyecto paralelo, es mucha infraestructura que mantener. A veces "suficientemente bueno" realmente es suficiente — especialmente cuando tus usuarios objetivo son desarrolladores europeos consultando dominios.

Qué significa esto para tu próximo proyecto

Hay una lección aquí que va más allá de las búsquedas de dominios: haz prefetch de forma inteligente. Si sabes lo que los usuarios podrían pedir a continuación, consíguelo antes de que lo pidan. Deja que la interfaz reaccione a lo que esté listo en lugar de esperar certezas.

La segunda lección tiene que ver con la elección de estructuras de datos. Un trie para datos calientes, una estructura ordenada bien indexada para todo lo demás. No necesitas mantener 240 millones de elementos en RAM si diseñas tus patrones de acceso alrededor de lo que realmente es probable que se solicite.

Finalmente, mide tu presupuesto real. En este caso: dos tecleos más un espacio. ¿Cuál es tu equivalente? Encuéntralo, optimiza hacia él, y deja de optimizar más allá.

El resultado se siente como magia. Pero empieza entendiendo exactamente cuánto tiempo tienes.