Una caché guarda temporalmente una copia de datos o resultados para evitar repetir un trabajo costoso. Puede acelerar una aplicación y reducir la presión sobre una base de datos o un servicio externo. Pero no es una mejora automática: añade reglas de actualización, riesgos de incoherencia y una nueva dependencia operativa.
La decisión útil no es «¿podemos poner una caché?», sino ¿qué operación concreta queremos mejorar y qué coste aceptamos a cambio? Esta guía ayuda a responderlo, desde el diagnóstico inicial hasta la validación y la retirada.
Qué problema resuelve una caché y qué problemas no corrige
Una caché es adecuada cuando una misma información o un resultado calculado se solicita repetidamente y producirlo de nuevo tiene un coste relevante. Ese coste puede ser tiempo de consulta, consumo de recursos, una llamada a otro servicio o latencia percibida por la persona usuaria.
En cambio, almacenar respuestas no corrige por sí mismo una consulta mal diseñada, un algoritmo ineficiente, una interfaz que hace peticiones de más ni una dependencia lenta en todos los casos. Puede ocultar esos defectos durante un tiempo, mientras hace más difícil diagnosticar el sistema. Si cada petición es distinta o los datos cambian continuamente, quizá haya pocos aciertos y la capa adicional no compense.
Antes de diseñar una caché, formula el objetivo de forma verificable: por ejemplo, reducir la latencia de una lectura frecuente o disminuir las consultas repetidas a una dependencia. Aclara también qué medida debe mejorar, en qué recorrido y para qué usuarios.
Señales para considerar una caché
La hipótesis gana fuerza si las mediciones muestran una combinación de estas señales:
- Lecturas repetidas: distintas peticiones necesitan los mismos datos o el mismo resultado dentro de un intervalo.
- Coste de origen elevado: consultar la base de datos, calcular una respuesta o llamar a un servicio tarda lo suficiente como para afectar al recorrido.
- Presión sobre una dependencia: el volumen de solicitudes amenaza su capacidad, sus límites o la estabilidad del sistema.
- Reutilización previsible: puedes identificar una clave estable que distingue resultados, como el idioma, los permisos o los filtros relevantes.
Una latencia alta aislada no basta. Comprueba dónde se consume el tiempo y si la mayoría de las peticiones podrían reutilizar un resultado. Mide los tiempos de respuesta por operación, el volumen, los errores y la frecuencia de repetición. Si la aplicación sirve contenido a usuarios distintos, verifica que la clave también distinga correctamente sus permisos y contexto.
Cuándo optimizar antes de añadir otra capa
Empieza por el origen cuando el problema se encuentra allí. Revisa consultas lentas, índices apropiados, datos innecesarios, llamadas redundantes y trabajo que podría ejecutarse una sola vez. Para una operación costosa, compara el coste de corregirla con el de mantener una caché. La optimización suele ser preferible si mejora todos los casos, incluidos aquellos que no pueden reutilizar una respuesta.
También conviene investigar si la lentitud aparece solo bajo concurrencia, en un servicio externo o en una parte concreta del recorrido. Una caché puede ayudar con algunas de esas situaciones, pero no necesariamente con todas. Si el resultado depende de información que cambia en cada solicitud, una copia almacenada puede ser inútil o engañosa.
Prueba primero la intervención más pequeña que pueda confirmar la causa. Si una consulta ajustada resuelve el problema, no hay motivo para asumir el coste de una capa adicional. Si persiste una repetición medible y el dato tolera cierta antigüedad, entonces tiene sentido evaluar la caché.
Qué datos almacenar y dónde hacerlo
Prioriza datos que se consultan a menudo, son caros de obtener y cambian con poca frecuencia, o cuyo retraso de actualización está expresamente aceptado. En cambio, evita almacenar sin un motivo claro datos personales o sensibles, información que requiere coherencia inmediata y resultados de baja reutilización. Define qué contiene cada entrada, cuánto puede ocupar, cómo se identifica y quién puede acceder a ella.
El ámbito depende del flujo:
- Cliente: puede evitar solicitudes repetidas en el navegador y mejorar la respuesta percibida. El servidor sigue siendo responsable de autorizar el acceso; no confíes en datos del cliente como fuente de permisos o verdad.
- Servidor: es útil cuando varios usuarios o peticiones pueden reutilizar el mismo resultado. La clave debe incluir todas las variables que cambian la respuesta, incluidas identidad, permisos y configuración cuando correspondan.
- Infraestructura: una caché de respuestas o contenido puede servir para solicitudes repetidas antes de que lleguen a la aplicación. Es importante configurar el alcance y las reglas de almacenamiento para no exponer respuestas privadas.
No elijas una ubicación por costumbre. Sigue el camino de los datos y decide dónde puede ocurrir la reutilización sin mezclar contextos ni incumplir requisitos de privacidad.
Expiración, invalidación y frescura
La expiración establece cuánto tiempo puede reutilizarse una entrada antes de considerarla caducada. Es sencilla, pero la información puede quedar desactualizada durante ese intervalo. La invalidación explícita elimina o actualiza entradas cuando cambia el dato de origen, aunque requiere conectar de forma fiable las escrituras con las claves afectadas. Ninguna estrategia es universal.
Para cada dato, acuerda una tolerancia máxima a la obsolescencia. Si una ficha informativa puede mostrar unos minutos de retraso, una duración acotada quizá sea aceptable. Para inventario, saldos, permisos o estados que condicionan una acción, determina si debe consultarse el origen antes de confirmar. No supongas que una caché garantiza coherencia entre réplicas o procesos.
Documenta qué evento invalida la entrada, qué ocurre si la actualización falla y cómo se evita que muchas solicitudes simultáneas vuelvan a calcular lo mismo. Si el negocio exige actualización inmediata, puede ser más apropiado no almacenar ese dato para el flujo crítico, o usar la caché solo como apoyo sin convertirla en autoridad.
Fallos y degradación controlada
Una caché puede no responder, perder entradas o devolver datos caducados. Decide de antemano qué hace la aplicación en cada caso: consultar el origen, devolver una respuesta limitada o mostrar un error. La alternativa depende de la importancia del dato y de la capacidad de la dependencia. Si todas las solicitudes pasan al origen a la vez tras una caída, la recuperación puede generar una sobrecarga adicional.
Define límites de memoria y comportamiento ante entradas inválidas. Para operaciones sensibles, verifica autorización en el momento adecuado y evita que una clave compartida exponga datos de otra cuenta. Trata los fallos de caché como una condición que se observa y prueba, no como una excepción improbable.
Cómo validar si la caché compensa
Establece una línea de base antes del cambio y compara el mismo recorrido después. Observa latencia, errores, carga sobre el origen y comportamiento bajo demanda representativa. Añade métricas de aciertos y fallos de caché, pero no confundas una tasa alta de aciertos con una mejora para el usuario: importa que el resultado final mejore sin degradar frescura o fiabilidad.
Revisa también los casos de expiración, invalidación y caída. Si el beneficio solo aparece en condiciones poco frecuentes, o el coste operativo supera el impacto medido, reconsidera la decisión. Mantén la capacidad de retirar la capa y comparar resultados, especialmente si cambian los patrones de uso.
Lista de comprobación antes de implementarla
- ¿Hay una operación concreta y una línea de base medible?
- ¿Se repiten las lecturas y es costoso obtener o calcular el resultado?
- ¿Se han descartado mejoras más simples en el origen?
- ¿Está definida la clave, incluidos permisos y contexto?
- ¿Se ha acordado cuánto retraso de datos es aceptable?
- ¿Existe un plan de expiración, invalidación y respuesta ante fallos?
- ¿Se medirán resultados para usuarios, carga y errores, además de aciertos?
Usa una caché cuando las mediciones confirmen una oportunidad de reutilización y puedas gobernar sus riesgos. Si no puedes explicar qué se almacena, durante cuánto tiempo y qué ocurre cuando está desactualizado, todavía falta una decisión de diseño esencial.