Saltar al contenido
Explorar conocimiento

concepto · intermedio · 3 min de lectura

Caching

El caching almacena copias de datos costosos de obtener en una capa de almacenamiento más rápida, reduciendo latencia y carga en los sistemas de origen para las solicitudes subsecuentes.

No requiere conocimientos previos.

Alcance en breve

Cubre

  • caching as a core architectural concept

No cubre

  • implementation details beyond conceptual understanding

Supone

  • The reader understands basic distributed systems concepts.

Resumen

Caching es la práctica de guardar temporalmente datos que son caros de computar o lentos de obtener, para servirlos rápido en solicitudes futuras. Es una de las optimizaciones más efectivas en sistemas de software: un cache hit —el dato está en cache— puede ser cientos o miles de veces más rápido que ir a la fuente original.

El caching se aplica en múltiples niveles: desde la caché L1/L2 del procesador hasta CDNs que cachean contenido en cientos de nodos globales. En aplicaciones web, los niveles más comunes son:

  • Cache de aplicación: en memoria del proceso, rápido pero volátil. Datos que cambian poco y se usan mucho —configuración, catálogos—.
  • Cache distribuido: Redis, Memcached. Compartido entre instancias, sobrevive a reinicios. Para sesiones, rate limiting, datos semi-estáticos.
  • Cache HTTP: headers Cache-Control, ETag, Last-Modified. El navegador o un proxy cachea respuestas completas.
  • Cache de base de datos: el motor ya cachea páginas de datos, índices y planes de consulta. Conocerlo evita caches redundantes.

Alcance y supuestos

Este paquete cubre el concepto a nivel arquitectónico: qué es, qué problema resuelve, cómo se relaciona con otros patrones del ecosistema, y en qué contexto tiene sentido aplicarlo. No cubre detalles de implementación específicos de cada tecnología ni configuraciones de proveedores cloud concretos. Asume que el lector entiende los fundamentos de sistemas distribuidos y arquitectura de software.

Modelo mental

La memoria de corto plazo de un ser humano. Si te pregunto «¿cuál es tu número de teléfono?», lo decís sin pensar: está en cache. Si te pregunto «¿qué comiste el 14 de marzo de 2019?», vas a necesitar un esfuerzo mucho mayor —o no vas a poder responder—. El caching es darle al sistema memoria de corto plazo para lo que se pregunta seguido.

Uso práctico

  • Datos leídos mucho más de lo que se escriben: perfiles de usuario, catálogos, configuraciones.
  • Operaciones costosas: resultados de queries agregadas, renders de plantillas, llamadas a APIs externas.
  • Datos que cambian constantemente: el saldo de una cuenta bancaria cacheado un minuto es un bug.
  • Sin estrategia de invalidación: «hay dos problemas difíciles en computación: nombrar cosas, invalidar caches y off-by-one errors.»

Estrategias de invalidación: TTL —el dato expira después de un tiempo—, write-through —escribir en cache y origen al mismo tiempo—, cache-aside —la app controla cuándo leer y escribir cache—.

Ejemplo trabajado: multi-nivel de cache en una app web

Una página de producto consulta: datos del producto (BD), precio con descuento (servicio externo), y stock (BD). Sin cache: ~300 ms. Con cache: el producto se cachea en Redis con TTL de 5 minutos (baja a ~5 ms), el precio se cachea localmente con TTL de 30 segundos (evita llamada externa), y el stock se consulta siempre —cambia constantemente y no tolera lecturas desactualizadas—. La página carga en ~15 ms en vez de 300 ms. La estrategia de invalidación varía por tipo de dato, no hay una regla única.

Evidencia

Fuentes citadas