Caché

En los sistemas backend, muchas solicitudes piden los mismos datos repetidamente, como perfiles de usuario, listas de productos o configuraciones. Consultar la base de datos cada vez introduce una latencia innecesaria y aumenta la carga del sistema.

El caché resuelve esto almacenando datos de acceso frecuente en una capa más rápida, normalmente en memoria. Cuando llega una solicitud, el sistema primero revisa el caché. Si los datos ya están allí, puede devolver el resultado de inmediato sin tocar la base de datos.

Esto mejora significativamente el tiempo de respuesta y reduce la presión sobre la base de datos, que normalmente es uno de los recursos más costosos y limitados de un sistema.

A alto nivel, el caché actúa como un atajo. En lugar de recalcular o volver a obtener los mismos datos repetidamente, el sistema reutiliza resultados recuperados previamente.

Cuando llega una solicitud, el sistema primero comprueba si los datos solicitados existen en la caché.

Si los datos se encuentran, esto se llama un acierto de caché. La respuesta se devuelve rápidamente porque evita una consulta a la base de datos, que es mucho más lenta.

Si los datos no se encuentran, esto se llama un fallo de caché. El sistema debe consultar la base de datos, recuperar los datos, almacenarlos en la caché y luego devolver la respuesta.

Este patrón crea dos rutas distintas:

Cache → Hit → respuesta rápida
Cache → Miss → base de datos → almacenar → respuesta

El objetivo de la caché es maximizar los aciertos de caché. Cuanto mayor sea la tasa de aciertos, más rápido será el sistema y menor será la carga sobre la base de datos.

Los datos en caché no pueden permanecer para siempre porque los datos subyacentes pueden cambiar. Si la caché no se actualiza, el sistema puede devolver información desactualizada o incorrecta.

Time-To-Live (TTL) resuelve esto al asociar un tiempo de expiración con cada entrada en caché. Después de que transcurre la duración del TTL, la caché elimina automáticamente los datos.

Por ejemplo, un catálogo de productos podría almacenarse en caché durante 5 minutos, mientras que una respuesta de API que cambia con frecuencia podría almacenarse en caché solo durante 60 segundos.

Elegir el TTL correcto es un compromiso. Un TTL más largo mejora el rendimiento al aumentar los aciertos de caché, pero corre el riesgo de servir datos obsoletos. Un TTL más corto mantiene los datos actualizados, pero aumenta la carga de la base de datos.

TTL es uno de los mecanismos más simples y más utilizados para mantener la corrección de la caché.

La caché introduce un problema fundamental: puede quedar desactualizada cuando cambian los datos subyacentes. Si el sistema sigue sirviendo datos antiguos desde la caché, los usuarios pueden ver información incorrecta.

La invalidación de caché resuelve esto al garantizar que, cuando los datos se actualizan en la base de datos, las entradas de caché correspondientes se eliminen o se refresquen.

Un enfoque común es eliminar la entrada de caché inmediatamente después de una actualización en la base de datos. La siguiente solicitud provocará un cache miss, obtendrá datos nuevos de la base de datos y almacenará el valor actualizado en la caché.

Otro enfoque es actualizar proactivamente la caché al mismo tiempo que cambia la base de datos, manteniendo ambas sincronizadas.

La dificultad está en identificar exactamente qué entradas de caché necesitan ser invalidadas. Los errores en este proceso son una fuente común de bugs en sistemas distribuidos.

En el patrón cache-aside, la aplicación es responsable de interactuar tanto con la caché como con la base de datos.

Cuando llega una solicitud, la aplicación primero verifica si los datos existen en la caché. Si existen (cache hit), los datos se devuelven de inmediato.

Si los datos no están en la caché (cache miss), la aplicación consulta la base de datos, obtiene el resultado, lo almacena en la caché y luego devuelve la respuesta.

Este enfoque se usa ampliamente porque es simple y flexible. La aplicación puede decidir qué almacenar en caché, cuándo hacerlo y cuánto tiempo debe permanecer allí.

Sin embargo, también significa que la aplicación debe manejar con cuidado la invalidación y la consistencia de la caché, ya que la caché no se mantiene sincronizada automáticamente con la base de datos.

En el caché de escritura directa, cada vez que se escriben datos, el sistema actualiza primero el caché y luego escribe los mismos datos en la base de datos. Esto garantiza que ambas capas siempre contengan el mismo valor.

Como el caché se actualiza de inmediato, cualquier lectura posterior devolverá los datos más recientes sin necesidad de consultar la base de datos. Esto simplifica la lógica de lectura y evita problemas de datos obsoletos.

La desventaja es que las operaciones de escritura se vuelven más lentas, ya que cada escritura debe realizarse dos veces: una en el caché y otra en la base de datos. Esto aumenta la latencia y puede reducir el rendimiento bajo cargas intensivas de escritura.

Además, el caché de escritura directa puede consumir más recursos porque ambas capas de almacenamiento se mantienen activamente. Aun así, es útil en sistemas donde la consistencia es crítica y se requiere un comportamiento de lectura predecible.

La caché se implementa usando diferentes tecnologías según dónde se ubique en el sistema.

Redis es uno de los sistemas de caché más utilizados. Almacena datos en memoria, lo que lo hace extremadamente rápido, y admite funciones como TTL, listas, conjuntos y otras estructuras de datos. Se usa comúnmente para caché a nivel de aplicación, sesiones y datos en tiempo real.

Memcached es otra caché en memoria, pero más simple que Redis. Se centra únicamente en el almacenamiento rápido de clave-valor y está optimizado para un alto rendimiento, lo que lo hace eficaz para casos de uso básicos de caché.

A un nivel más alto, las CDNs (Content Delivery Networks) almacenan en caché contenido estático como imágenes, videos y HTML en servidores distribuidos por todo el mundo. Esto reduce la distancia que deben recorrer los datos, mejorando el rendimiento para usuarios globales.

En muchos sistemas, estas tecnologías se combinan. Una solicitud puede llegar primero a una CDN, luego a una caché de aplicación como Redis, y solo alcanzar la base de datos si es necesario.

El almacenamiento en caché no se limita a un solo lugar: se usa en varias capas de un sistema backend.

En el borde, las CDN almacenan contenido estático cerca de los usuarios, reduciendo la latencia de red. En la capa de aplicación, herramientas como Redis o Memcached almacenan en caché datos de acceso frecuente, como sesiones de usuario o respuestas de API.

Algunas bases de datos también incluyen caché de consultas, guardando resultados de consultas frecuentes para evitar recomputaciones.

Estas capas forman una jerarquía:

Client → CDN → Application Cache → Database

Cada capa absorbe parte de la carga de solicitudes, asegurando que solo se acceda a la base de datos cuando sea necesario. Este enfoque por capas es fundamental para escalar sistemas de manera eficiente.

La caché es una de las formas más efectivas de mejorar el rendimiento del sistema. Al servir datos desde un almacenamiento más rápido, los sistemas pueden responder con mayor rapidez y manejar mucho más tráfico con menos carga en la base de datos.

Sin embargo, esta mejora de rendimiento tiene compromisos. El problema más importante son los datos obsoletos: los valores en caché pueden dejar de reflejar el estado más reciente de la base de datos.

Garantizar la consistencia entre la caché y la base de datos introduce complejidad adicional. Los desarrolladores deben diseñar cuidadosamente estrategias de invalidación para mantener los datos precisos.

En la práctica, la caché es un equilibrio. Los sistemas intercambian cierto nivel de consistencia y complejidad a cambio de mejoras importantes en velocidad y escalabilidad.