A veces el problema no es dónde guardar los datos, sino cuántas veces los pides. Si tu aplicación consulta una y otra vez la misma información a la base de datos, la estás sobrecargando y ralentizando. La solución es una caché en memoria, y en AWS se llama ElastiCache. Este subcapítulo te explica qué es y por qué puede transformar el rendimiento de tu aplicación.

Imagina una web de noticias donde 100.000 personas leen el mismo artículo popular. Sin caché, cada visita hace que la aplicación vaya a la base de datos a buscar el mismo artículo, una y otra vez. La base de datos hace el mismo trabajo 100.000 veces y se satura.

Las bases de datos guardan los datos en disco, que es relativamente lento. ¿Y si guardáramos los datos más pedidos en un lugar mucho más rápido para no molestar a la base de datos cada vez?

Una caché es un almacén temporal y muy rápido donde guardas los datos que más se consultan, para servirlos al instante sin ir a la fuente original (la base de datos).

La clave: la caché guarda los datos en memoria RAM, que es muchísimo más rápida que el disco. Leer de memoria es cuestión de microsegundos.

Analogía: Imagina a un cocinero en un restaurante con mucho trajín.

• Sin caché: cada vez que necesita sal, baja al almacén del sótano (la base de datos, en disco: lento). Mil platos = mil viajes al sótano.
• Con caché: tiene la sal y los ingredientes más usados en la encimera, a mano (la caché, en memoria: rapidísimo). Solo baja al sótano para lo poco frecuente.

El resultado: sirve los platos muchísimo más rápido y el almacén (la base de datos) descansa.

ElastiCache es el servicio gestionado de AWS para ejecutar cachés en memoria. Soporta dos tecnologías muy populares:

En la mayoría de casos modernos se usa Redis por sus funciones adicionales, pero Memcached sigue siendo válido para cachés sencillas.

Como servicio gestionado (igual que RDS), AWS se encarga de la instalación, los parches y la infraestructura; tú solo usas la caché.

El patrón más común se llama cache-aside («caché al lado»). Funciona así:

• La primera vez que se pide un dato, no está en la caché (miss): se busca en la base de datos y se guarda en la caché.
• Las siguientes veces, ya está en la caché (hit): se sirve al instante sin tocar la base de datos.

Ejemplo real: En la web de noticias, el primer lector del artículo popular hace que se cargue desde la base de datos y se guarde en la caché. Los siguientes 99.999 lectores lo reciben directamente desde la caché, en microsegundos, sin molestar a la base de datos. La web va volando y la base de datos apenas trabaja.

• Acelerar lecturas frecuentes: los datos «calientes» (los más pedidos) se sirven desde memoria.
• Aliviar la base de datos: menos consultas repetidas = base de datos más descansada y barata.
• Guardar sesiones de usuario: información de la sesión de cada usuario, accesible al instante.
• Tablas de clasificación (leaderboards) en videojuegos: Redis es excelente para rankings en tiempo real.
• Limitar peticiones (rate limiting): controlar cuántas veces alguien hace algo en un periodo.

Lo más importante que debes entender: la caché es temporal y puede perderse. No es la fuente «de verdad» de tus datos; es una copia rápida de lo que ya está en la base de datos.

Por eso:

• Los datos en caché tienen un tiempo de vida (TTL): caducan tras un periodo para no servir información obsoleta.
• Nunca uses la caché como único lugar para datos importantes. La fuente de la verdad es siempre la base de datos; la caché solo acelera el acceso.

El reto de las cachés — la invalidación: existe una famosa frase en informática: «solo hay dos cosas difíciles en programación: invalidar la caché y nombrar las cosas». El reto es asegurarte de que, cuando un dato cambia en la base de datos, la copia en caché se actualiza o se borra, para no servir información vieja. Por eso se usan los TTL y estrategias de actualización.

• Una caché en memoria guarda los datos más consultados en RAM (rapidísima) para no ir a la base de datos (disco, más lento) cada vez.
• ElastiCache es el servicio gestionado de AWS para cachés, con Redis (más completo) y Memcached (más simple).
• El patrón típico (cache-aside): mira la caché primero; si está (hit), respuesta instantánea; si no (miss), va a la base de datos y guarda una copia.
• Beneficios: acelera las lecturas y alivia la base de datos. Ideal para datos «calientes», sesiones y rankings.
• La caché es temporal: usa TTL, mantenla actualizada y nunca la conviertas en el único lugar de datos importantes.

En el último subcapítulo del capítulo (y de la Parte II) pondremos orden a todo: cuándo usar cada tipo de base de datos que hemos visto.