Definición
Una caché es una copia de un dato guardada en un lugar más rápido o más cercano, para no tener que volver a calcularlo, consultarlo o descargarlo.
El principio es siempre el mismo: lo caro se hace una vez y se reutiliza. Si una consulta tarda dos segundos y el resultado no cambia en una hora, no tiene sentido pagar esos dos segundos mil veces.
Hay una broma vieja en el oficio que resulta ser cierta: "solo hay dos problemas difíciles en informática: invalidar la caché y ponerle nombre a las cosas". Cachear es fácil. Saber cuándo la copia dejó de ser válida es donde está el trabajo.
Dónde se cachea
En una web hay caché en muchas capas a la vez, y conviene saber cuáles:
En el navegador. Guarda imágenes, CSS y JavaScript según lo que digan las cabeceras HTTP.
En la CDN. Servidores repartidos por el mundo que guardan copia de lo estático cerca del visitante.
En el servidor de aplicación. Guardar en memoria el resultado de algo costoso: una consulta pesada, el renderizado de una página.
En una caché compartida (Redis, Memcached). Cuando hay varios servidores y todos tienen que ver lo mismo.
En la base de datos. El propio motor cachea páginas de datos y planes de consulta.
Las cabeceras que lo controlan
En la web, casi todo se decide con Cache-Control:
no-store— no guardes nada. Para datos privados.no-cache— puedes guardarlo, pero pregunta si sigue vigente antes de usarlo.max-age=3600— válido una hora sin preguntar.immutable— no va a cambiar nunca, no preguntes.
Y el patrón que resuelve el problema de fondo: poner una huella en el nombre del fichero. En vez de estilos.css, estilos.a3f9c1.css. Como el nombre cambia cuando cambia el contenido, puedes cachearlo para siempre sin miedo: cuando publiques una versión nueva, el nombre será otro y el navegador la pedirá.
Ejemplo práctico
Tengo dos casos opuestos que enseñan las dos caras.
Donde la caché salvó la factura: el asistente de IA del CRM. Cada llamada al modelo reenvía el mismo bloque de instrucciones —cientos de tokens— además de la pregunta. Marcando ese bloque para que el proveedor lo cachee, esa parte pasa a costar una fracción. Es el mayor ahorro disponible en cualquier asistente con instrucciones largas.
Donde la caché me dio un problema: el teléfono asistente de aeworks.tech usa una imagen. Al cambiarla, seguía viéndose la antigua por mucho que recargara. La solución fue añadir a la dirección de la imagen un parámetro con la fecha de modificación del fichero. Cuando el fichero cambia, la dirección cambia, y el navegador se ve obligado a pedirla de nuevo.
Y el caso más molesto de todos, que además es el más común: una PWA con su service worker cacheando de más. El usuario recarga, recarga otra vez, y sigue viendo la versión vieja porque el script se la está sirviendo desde la caché antes de llegar a la red. Ahí no basta con recargar: hay que versionar la caché y tener un plan de actualización desde el primer día.
Estrategias de invalidación
- Por tiempo de vida. Simple y suficiente para casi todo. El dato caduca solo.
- Al escribir. Cuando modificas el dato, borras la copia. Preciso y hay que acordarse en todos los sitios donde se escribe.
- Por versión en el nombre. El mejor patrón para ficheros estáticos. No se invalida: se sustituye.
- Refresco en segundo plano. Sirves la copia vieja mientras generas la nueva. El usuario nunca espera.
Errores comunes
- Cachear datos privados en una caché compartida. Es la forma de acabar enseñándole a un cliente los datos de otro. De los fallos más graves que se pueden cometer.
- Cachear sin plan de invalidación. Si no sabes cómo vas a limpiarla, todavía no la montes.
- Tiempos de vida eternos en contenido que cambia. Precios y stock con una hora de caché son una reclamación esperando a ocurrir.
- No medir si sirve. Una caché con muy pocos aciertos añade complejidad y no gana nada.
- Usarla para tapar una consulta mal hecha. Si la consulta tarda dos segundos porque le falta un índice, arregla el índice.
Cuándo usarla
Sí cuando el mismo cálculo se repite mucho, cuando el dato cambia poco comparado con cuánto se lee, o cuando dependes de un servicio externo lento o que cobra por consulta.
No todavía, si aún no has medido dónde está el problema. La caché es una optimización, y optimizar sin medir es adivinar. Primero mide, después arregla lo que se pueda arreglar de raíz, y solo entonces cachea lo que quede.
