Autocomplete p99 0 ms para 240M dominios: la arquitectura de Wirewiki

El reto: autocomplete de dominio que se sienta instantáneo

Ruurtjan Kramer corre Wirewiki.com, una herramienta para inspeccionar infraestructura de internet: registros DNS históricos, delegación, configuración de entregabilidad de email. El espacio está saturado — cada vez hay más sitios que ofrecen lo mismo gracias al vibe coding — así que su apuesta para diferenciarse fue calidad de herramienta y experiencia de usuario.

El autocomplete es la forma principal de navegar Wirewiki, así que tiene que ser lo más completo, exacto y rápido posible. El objetivo que se planteó fue p99 0 ms: que el 99% de las veces los resultados estén listos antes de que el usuario suelte la tecla. La coletilla del asterisco en el título (“p99 0 ms*”) anticipa la advertencia: es 0 ms para tráfico cerca del servidor europeo, no para usuarios en otros continentes.

Cómo se mide el presupuesto de latencia

Kramer redefinió latencia como tiempo entre keyUp y resultados listos para renderizar. Un display de 60 Hz refresca cada 16,7 ms, lo que da 8,33 ms extra a p50 pero cerca de 0 ms a p99.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

La técnica para exprimir ese presupuesto: en keyDown se hace prefetch del carácter tipeado más el siguiente; en keyUp se renderiza. Así se aprovecha la duración de dos pulsaciones más el gap entre ellas. Kramer midió tecleando 100 dominios a velocidad razonable y obtuvo un p99 de 121 ms — ese es el presupuesto total disponible.

Para que el resultado esté listo al soltar la tecla hacen falta dos cosas: prefetch y caché del lado del cliente, y una API lo bastante rápida del lado del servidor.

La arquitectura de la API: cabeza Tranco + cola CZDS

La API divide el problema en dos mitades. La cabeza son los dominios más populares, servidos desde una estructura de datos trie (prefix tree) en memoria con los 8 mejores sugerencias precalculadas por cada prefijo. Una búsqueda es un recorrido de unos pocos punteros — complejidad O(longitud de lo tipeado), que en la práctica es O(1) porque la longitud está acotada.

La cola es el long tail: 240 millones de nombres de dominio almacenados ordenados y comprimidos con delta-encoding en bloques de tamaño fijo, servidos desde un índice SSD memory-mapped con un directorio diminuto de 27 MB en memoria. La búsqueda hace binary search sobre el directorio y luego escanea linealmente un bloque de 256 nombres. Los 240M de dominios ocupan unos 2,5 GB en disco, y las páginas calientes quedan cacheadas en RAM por el sistema operativo. Aquí la complejidad es O(longitud × log(n)), también acotada en la práctica.

Para la cabeza, Kramer usa la lista Tranco, el ranking académico abierto del millón de dominios más populares — un recurso que, según reportó KrebsOnSecurity en noviembre de 2025, es ampliamente usado para trust and safety por navegadores, resolvedores DNS y APIs de safe browsing. Para la cola usa CZDS (Centralized Zone Data Service) de ICANN, que da las zonas de la mayoría de gTLDs (.com, .net, .org). Los ccTLDs (.uk, .de, .fr) no están disponibles, pero los dominios con tráfico significativo suelen estar en Tranco de todos modos. Certificate Transparency logs y Archive.org quedan como fuentes pendientes de integrar.

Los resultados vuelven en orden de ranking: los primeros 8 son los más populares.

Cómo se mide: 720.000 queries simuladas a 60.000 dominios

Kramer no se quedó en benchmarks optimistas. Un LLM generó 720.000 queries de pulsaciones simulando 60.000 dominios tipeados y los reprodujo en bucle abierto — disparando a tasa fija sin esperar respuestas — contra el servidor de producción. La prueba se hizo con la API aislada, a través de Nginx, y end-to-end.

Los resultados: la mayoría de requests se responden en menos de 2 ms. Incluso a 1.600 req/s, Nginx + la API responden en 15 ms el 99% del tiempo. En la práctica, la latencia del autocomplete es aproximadamente el round-trip desde el navegador hasta el servidor (vía Cloudflare) más 10 ms.

El asterisco:地理 y CDN

El asterisco del título existe por una decisión que Kramer no toma. El servidor único en ese continente favorece a Europa; tráfico desde EE. UU. suma 100–200 ms y rompe el presupuesto p99. La solución obvia es multi-región con geo load balancing — daría p99 0 ms de verdad — pero Kramer lo descarta: sería demasiado incluso para él, y cree que este nicho no da para construir un negocio encima. Pide contacto por email si alguien pagaría por acceso a la API.

Mientras tanto, CDN caching de paths calientes y el umbral de Nielsen Norman de 0,1 s como respuesta “instantánea” absorben parte de esa distancia — pero no lo suficiente para alcanzar el objetivo desde fuera de Europa.

Qué significa esto para tu startup

Para una startup que esté diseñando una funcionalidad de búsqueda con latencia crítica, el caso de Wirewiki destila tres lecciones reutilizables:

Piensa en latencia como presupuesto humano, no como métrica de servidor. Kramer redefinió “instantáneo” usando el tiempo entre keyDown y keyUp, no el tiempo de respuesta del backend. Esa traducción de fisiología humana a requisitos técnicos es lo que permite pedirle a la API 121 ms en lugar de adivinar.
Divide el espacio de búsqueda en cabeza y cola, y elige una estructura de datos distinta para cada una. El trie en memoria sirve para los top-N donde el ranking es estable; el índice memory-mapped sirve para el resto donde lo que importa es binary search + scan acotado. Misma complejidad asintótica, pero cada uno optimiza para su régimen.
Mide en producción con tráfico sintético agresivo. 720.000 queries generadas por LLM y reproducidas en open-loop es más barato y revelador que cualquier prueba sintética de laboratorio. Si tu producto depende de latencia, este es el patrón a copiar.