Buscapalabra.com nació en 2010 como una herramienta personal para resolver un problema concreto: encontrar palabras que cumplieran restricciones ortográficas específicas para juegos de palabras y crucigramas. Catorce años después, procesa más de 100 millones de consultas anuales y se ha convertido en un recurso de referencia para estudiantes, profesores y aficionados a los juegos de lenguaje en todo el mundo hispanohablante.
Cómo empezó
La primera versión era un script PHP de 200 líneas que cargaba un diccionario en memoria por cada request. Funcionaba perfectamente para el tráfico inicial —unas pocas decenas de visitas diarias— pero la arquitectura no iba a escalar.
El problema fundamental del proyecto es que las consultas son computacionalmente baratas pero el volumen es alto. Una búsqueda por patrón (por ejemplo, “palabras de 7 letras que empiecen por T y tengan una X en la cuarta posición”) requiere recorrer un diccionario de ~80.000 entradas aplicando un filtro. En términos de complejidad, es O(n) con n constante.
La evolución de la arquitectura
Fase 1 (2010-2015): PHP monolítico
Un único servidor VPS, diccionario cargado desde disco en cada request, sin caché. El punto de quiebre llegó cuando un artículo en un foro educativo generó un pico de tráfico que saturó la CPU.
Fase 2 (2015-2019): Caché agresiva
Introduje Redis para cachear los resultados de las consultas más frecuentes. Descubrí algo interesante: el 80% del tráfico se concentraba en menos del 5% de los patrones de búsqueda posibles (ley de Pareto aplicada a los crucigramas). La tasa de hit en caché llegó al 94%, lo que redujo la carga del servidor en un factor de ~15.
Fase 3 (2019-presente): Precomputación y edge caching
La optimización más impactante fue conceptualmente la más simple: para las consultas más frecuentes (aproximadamente 50.000 patrones), precomputé los resultados y los almacené como archivos estáticos. Combinado con un CDN que los sirve desde edge nodes geográficamente distribuidos, la latencia para estas consultas pasó de ~200ms a ~15ms.
Lecciones de ingeniería
1. Conoce tu distribución de uso antes de optimizar. La curva de distribución del tráfico tiene forma de ley de potencias en casi todos los sistemas de consulta. Identificar el percentil 95 de las queries más frecuentes y optimizar para ese caso te da retornos enormes.
2. Lo simple escala mejor que lo sofisticado. Cada vez que evalué introducir un motor de búsqueda más sofisticado (Elasticsearch, Solr), los números no justificaban la complejidad añadida. La solución más tonta que funciona suele ser la correcta.
3. Las métricas de negocio y las técnicas no siempre se alinean. La latencia p99 es importante, pero lo que los usuarios perciben es si la página “se siente rápida”. A veces un skeleton loader bien diseñado mejora más la experiencia que reducir el tiempo de respuesta en 50ms.
El componente pedagógico inesperado
Lo más curioso de Buscapalabra ha sido descubrir que una parte significativa del tráfico proviene de aulas. Profesores de primaria y secundaria lo usan para generar listas de palabras con criterios fonéticos para actividades de comprensión lectora. Esta segunda vida del proyecto —que nunca diseñé— es la que encuentro más satisfactoria.
Hay algo poético en que una herramienta que nació de la obsesión privada por los crucigramas acabe siendo útil para que los niños aprendan a leer.
