¿Por qué una página que ya visitaste carga más rápido la segunda vez? ¿Por qué algunas aplicaciones responden casi al instante aunque trabajen con enormes cantidades de datos? En muchos casos, la respuesta es la caché. Se trata de una de las técnicas más usadas en el desarrollo backend para mejorar el rendimiento, y entenderla ayuda tanto a quienes programan como a quienes quieren comprender cómo funcionan las aplicaciones por dentro. En este artículo verás qué es, cómo trabaja y qué precauciones conviene tomar.
¿Qué es la caché?
La caché es un almacenamiento temporal y rápido donde se guardan copias de datos que se piden con frecuencia o que son costosos de calcular. En lugar de repetir una operación lenta cada vez, como consultar una base de datos o llamar a un servicio externo, el sistema primero busca el resultado en la caché. Si lo encuentra, lo devuelve de inmediato. Si no, hace el trabajo completo y guarda el resultado para la próxima vez.
Una buena analogía es la de un cocinero que deja a mano los ingredientes que más usa, en lugar de ir a la despensa cada vez. Es mucho más rápido, siempre que lo que tiene a mano siga siendo bueno.
Aciertos y fallos de caché
Dos términos aparecen constantemente al hablar de este tema:
- Cache hit (acierto): el dato solicitado estaba en la caché y se entregó rápidamente.
- Cache miss (fallo): el dato no estaba, por lo que hubo que obtenerlo de la fuente original.
Cuanto mayor sea la proporción de aciertos, más útil resulta la caché. Por eso conviene guardar datos que se leen muchas veces y cambian poco.
Dónde puede haber caché
La caché no vive en un único lugar. Existen varias capas, y cada una resuelve un problema distinto:
| Capa | Qué guarda | Ejemplo |
|---|---|---|
| Navegador | Archivos estáticos como imágenes, estilos y scripts | Una imagen que no se vuelve a descargar |
| CDN | Contenido copiado en servidores cercanos al usuario | Archivos de un sitio servidos desde un punto cercano |
| Aplicación | Resultados de cálculos o de consultas | Una lista de productos ya consultada |
| Almacén en memoria | Datos en una base de datos muy rápida, compartida entre servidores | Sesiones o contadores |
| Base de datos | Páginas de datos y planes de consulta usados con frecuencia | Resultados recientes de consultas |
Estrategias habituales
Existen varias formas de decidir cómo leer y escribir en la caché. Estas son las más conocidas:
- Cache-aside (carga bajo demanda): la aplicación pregunta primero a la caché. Si hay un fallo, consulta la fuente, guarda el resultado y lo devuelve. Es la estrategia más común por su simplicidad.
- Write-through: cada vez que se escribe un dato, se actualiza a la vez la fuente y la caché, de modo que ambas se mantienen coherentes.
- Write-back: se escribe primero en la caché y, más tarde, en la fuente. Es rápido, pero hay riesgo de perder datos si algo falla antes de guardarlos.
El gran problema: la invalidación
Hay una frase muy repetida entre programadores: una de las cosas más difíciles de la informática es saber cuándo invalidar la caché. La razón es sencilla. Una copia solo es útil mientras siga siendo correcta. Si el dato original cambia y la caché sigue mostrando el valor viejo, los usuarios verán información desactualizada.
Para manejarlo se usan principalmente dos recursos:
- TTL (time to live): cada dato se guarda con un tiempo de vida. Pasado ese tiempo, expira y se vuelve a pedir a la fuente. Es fácil de aplicar, pero acepta cierto retraso en las actualizaciones.
- Invalidación explícita: cuando el dato cambia, se borra o se actualiza la entrada de la caché en ese mismo momento. Es más precisa, pero exige más cuidado en el código.
Además, como la caché tiene un tamaño limitado, necesita una regla para decidir qué eliminar cuando se llena. Una política muy usada es LRU (menos usado recientemente), que descarta primero los datos que llevan más tiempo sin consultarse.
Qué conviene guardar en caché (y qué no)
- Buenos candidatos: datos que se leen mucho y cambian poco, resultados de cálculos costosos, respuestas de servicios externos lentos y contenido público igual para todos.
- Candidatos peligrosos: datos que cambian constantemente, información sensible o personal que no debe mezclarse entre usuarios y datos que exigen exactitud absoluta, como saldos en operaciones críticas.
Errores comunes
- Guardar en caché sin medir primero si realmente hay un problema de rendimiento.
- Usar claves poco precisas y entregar a un usuario los datos de otro.
- Olvidar la expiración y acumular datos viejos.
- Depender de la caché de tal forma que, si falla, el sistema entero deja de funcionar.
- Cuando muchas entradas expiran al mismo tiempo, provocar un pico de peticiones a la fuente original.
Buenas prácticas
- Medir antes y después para comprobar que la caché mejora el rendimiento.
- Definir un TTL razonable según qué tan fresco debe ser cada dato.
- Diseñar claves claras que incluyan todo lo que hace único al dato.
- Monitorear la tasa de aciertos y el uso de memoria.
- Pensar siempre en qué ocurre si la caché está vacía o no disponible.
Conclusión
La caché es una herramienta poderosa para hacer aplicaciones más rápidas y reducir la carga de los sistemas, pero exige criterio: decidir qué guardar, por cuánto tiempo y cómo mantenerlo actualizado. Si quieres seguir aprendiendo sobre bases de datos, APIs y arquitectura de aplicaciones, te invitamos a conocer los cursos de desarrollo backend y tecnología de la información disponibles en Cursa.
