Cachear o no Cachear… Esa es la cuestión…
Hola amante de hacer todas las peticiones a la base de datos,
Hoy te voy a explicar una de esas cosas que no te enseñan en los bootcamps o en la universidad, pero que aprendes después de publicar tu primera aplicación en producción.
Y es que esto no es algo que se suela pensar cuando estás felizmente desarrollando tu aplicación, pero si no lo haces te va a pasar factura.
A ver si te suena esto…
Acabas de publicar tu primera aplicación en producción, que guay, que nervios.
Pruebas y va bien la cosa.
Que bien verdad.
Tu aplicación empieza a crecer y empieza a tener muchos usuarios, que se traduce en muchas peticiones.
Y …
🤔 “¿Por qué esta consulta tarda tanto?”
🤔 “¿Esta consulta, que se hace cada dos por tres, no está haciendo consultas innecesarias a la base de datos?”
🤔 “¿De verdad necesito estar calculando esto cada vez que alguien lo pide?”
O ves que se está saturando la carga en la base de datos y te preguntas:
🤔 “¿Cómo puedo reducir la carga en la base de datos?”
Y ahora te empiezan a llegar comentarios de tus usuarios porque la aplicación no funciona.
Bueno, si te has llegado a hacer estas preguntas, déjame decirte que vas por el camino correcto.
Y por eso hoy te voy a hablar de esta “herramienta” tan poderosa para mejorar el rendimiento de tu aplicación.
Y es nada más, y nada menos que….
LA CACHÉ
Breve resumen por si te ha sonado a chino:
Cachear significa almacenar temporalmente datos en memoria para evitar cálculos repetitivos o consultas innecesarias.
-“Ahh, vale, ósea que esto me va a ayudar con las consultas innecesarias y los tiempos de algunas peticiones”.
¡Eso es!
¿Y esto cómo se consigue?
Pues mira:
✅ Menos carga en la base de datos → Si los datos no cambian con frecuencia, ¿para qué consultarlos cada vez?
✅ Respuestas más rápidas → Leer desde memoria es miles de veces más rápido que hacer una consulta a disco.
✅ Escalabilidad → Reduce la presión en la infraestructura, permitiendo manejar más usuarios con menos recursos.
Pero mejor… vamos con el ejemplo.
Ponte que tienes una tienda online, y estás montando una consulta para traer los 10 productos más vendidos.
Aquí montarías el típico repositorio que hace la query a la base de datos con:
productoRepository.findTop10ByOrderByVentasDesc();O como lo quieras escribir.
Ahora piensa que si esta consulta se ejecuta cada vez que alguien entra en la tienda, nuestra base de datos sufrirá. 😅
-“Vale…. Pero es que en mi tienda entra poca gente…”
Bueno, pues imagínate que tu tienda es Amazon…. Dónde entran millones de usuarios… y ya la consulta empieza a “escocer” y a ralentizar tu aplicación.
(Si eres Amazon, no quieres que la gente deje de usar tu aplicación porque una consulta tarda a la base de datos)
Pues esta consulta es una buena candidata para cachear.
Y así, si millones de usuarios hacen la petición, no se están haciendo millones de consultas a la base de datos.
-“Vale, me ha gustado lo que me cuentas…. Pero…. ¿Qué debería de cachear?”
Bueno, aquí no hay una solución clara, de esto sí y esto no, esto tendrás que verlo tú, aplicado a tu aplicación y lógica de negocio, porque si con el ejemplo anterior es una petición que se hace en un sitio muy específico… pues no la cachearíamos.
Ahora…. Cuándo me lo plantearía:
🔹 Cuando los datos no cambian constantemente → Ejemplo: listas de productos, rankings, configuraciones.
🔹 Cuando las consultas son pesadas → Evita cálculos innecesarios o queries costosas.
🔹 Cuando la velocidad es clave → APIs de alta concurrencia se benefician mucho de una respuesta rápida.
📌 Opciones populares de caché:
🔹 Redis → Rápido, persistente y con soporte para estructuras de datos avanzadas.
🔹 Memcached → Ultraligero y eficiente para datos volátiles.
¡Pero cuidado!
No todo es oro lo que reluce, porque el tema de la caché es un arma de doble filo y tienes grandes peligros:
🔻 Incoherencia de datos → Si un dato cambia en la base de datos y no actualizas la caché, podrías estar sirviendo información obsoleta.
🔻 Uso excesivo de memoria → Cachear TODO puede ser contraproducente si consumes demasiados recursos.
🔻 Estrategias de invalidación mal diseñadas → Si no decides bien cuándo refrescar la caché, puedes terminar con datos desactualizados o un caché inútil.
Así que nada, ahora te toca darle una vuelta a esto de la caché y ver qué cosas puedes cachear.
¡Nos leemos dentro de una semana!