Caché en servidores MCP: Lo que aprendí tras 87 caídas
Pensé que mi servidor MCP no necesitaba caché.
Mi base de conocimientos solo tenía unos pocos miles de entradas. Las consultas eran rápidas. Me equivoqué.
Tras 87 caídas en producción y tres días depurando tiempos de espera (timeouts), aprendí una dura lección. Todo servidor MCP necesita caché. Incluso los pequeños.
Esto es lo que pasó.
El servidor utilizaba búsqueda semántica para encontrar notas. La mayoría de las veces funcionaba. Pero entonces, las cosas fallaron.
- Las conexiones se caían a mitad de la solicitud.
- Claude Desktop agotaba el tiempo de espera tras 60 segundos.
- Nginx devolvía errores 504 Gateway Timeout.
¿Lo peor? Solo ocurría con consultas repetidas.
Cuando un usuario hace la misma pregunta dos veces, la conexión puede quedar inactiva mientras la IA piensa. Un proxy corta entonces la conexión. Claude reintenta la solicitud automáticamente. Ahora, tienes dos búsquedas idénticas ejecutándose al mismo tiempo.
Cuando ocurren múltiples reintentos, el pool de conexiones de tu base de datos se agota. Todo muere.
Me di cuenta de que no debía cachear la respuesta final de la IA. Eso es demasiado complejo para MCP. En su lugar, tenía que cachear la parte pesada: la búsqueda semántica y la obtención de contenido.
Pasé a una estrategia de caché de dos niveles:
• Nivel 1: Caché en memoria para consultas frecuentes. Es extremadamente rápido. • Nivel 2: Caché Redis para datos compartidos entre reinicios.
También seguí estas reglas para que funcionara:
- Normalizar consultas: Convierto las consultas a minúsculas y elimino los espacios adicionales. Esto aumenta los aciertos de caché.
- Cachear resultados, no flujos (streams): Solo cacheo los resultados de la búsqueda. La búsqueda consume el 95% del tiempo.
- Degradación controlada: Si Redis se cae, el servidor sigue funcionando. Simplemente va directamente a la base de datos. El caché es una optimización, no un requisito para que la solicitud tenga éxito.
Los resultados fueron masivos.
Mi tiempo de búsqueda promedio pasó de 320 ms a 12 ms. Eso es 27 veces más rápido. Mi tasa total de aciertos de caché es del 73%. La mayoría de las consultas ni siquiera llegan a mi base de datos.
Si construyes un servidor MCP, haz esto:
- Para uso personal: Usa un caché en memoria. Evita los tiempos de espera aleatorios.
- Para servicios públicos: Usa el enfoque de dos niveles con Redis. Evita caídas y mejora la velocidad.
El caché trata sobre la fiabilidad. Detiene el ciclo de reintentos y fallos de conexión.
Comunidad de aprendizaje opcional: https://t.me/GyaanSetuAi