El mapa: 20 conceptos en siete grupos

Un mapa de metro: primero ves todas las líneas a la vez, luego recorres estación por estación.

Primero van tres básicos — qué es una cache, hit y miss, y por qué funciona. Luego seis grupos, uno por capítulo: las capas de cache, el hit ratio, la frescura, las estrategias para actualizar y desalojar, las trampas y cómo usarla bien.

Cada concepto siguiente tiene la misma forma: su nombre en inglés (apréndelo — es el término), una imagen de la vida cotidiana, un diagrama y una ficha con los campos problema, idea, ejemplo, coste, cuándo usarlo y relaciones.

Cache — una cache recuerda la respuesta

Un cuaderno de notas en tu escritorio junto a un archivador lento — una vez que has buscado algo, lo apuntas, y la próxima vez lees la nota en lugar de cruzar la sala otra vez.

Una cache es un almacén pequeño y rápido que guarda el resultado de un trabajo costoso — una consulta a la base de datos, una página calculada, un archivo descargado — para que la siguiente petición sea barata. Lo costoso ocurre una vez; la lectura barata, muchas veces. Ese es todo el principio. Lo demás son detalles sobre dónde vive el cuaderno y cuándo fiarse de lo que hay escrito.

Cache hit y cache miss — los dos resultados

Buscas la nota. O está ahí y la lees al instante — o está en blanco y, después de todo, tienes que ir al archivador.

Cuando la respuesta está en la cache, es un cache hit — rápido y barato. Cuando no está, es un cache miss — haces el trabajo lento y normalmente guardas el resultado para que la próxima vez sea un hit. Estas dos palabras describen toda interacción con una cache. El juego del caching consiste en convertir misses en hits.

Locality — funciona gracias a la repetición

Una cafetería que memoriza los pedidos de sus clientes habituales — compensa solo porque las mismas personas piden lo mismo una y otra vez.

El caching compensa cuando las mismas respuestas se necesitan repetidamente — y casi todo en la informática es repetitivo. Esta propiedad se llama locality (localidad): el acceso no es aleatorio, sino que se concentra en unos pocos elementos calientes. La misma página popular, el perfil del mismo usuario, la misma búsqueda, pedidos miles de veces. Así, una cache pequeña con los populares puede absorber una gran parte del trabajo. Sin repetición, no hay motivo para cachear.

Cache Hierarchy — cuanto más cerca la cache, más rápido el hit

Suministros que guardas en tu escritorio, en la habitación, en el edificio y en un almacén al otro lado de la ciudad — cuanto más cerca, más rápido los consigues, pero menos cabe.

Hay una escalera de caches entre un usuario y la verdad — una cache hierarchy (jerarquía de caches): el navegador guarda archivos en tu dispositivo, una CDN guarda copias cerca de tu ciudad, la aplicación mantiene datos calientes en memoria y la CPU tiene caches diminutas a nanosegundos. Las caches más cercanas son más rápidas pero más pequeñas. Una petición prueba primero la más cercana y, si falla, sigue hacia fuera.

In-memory Cache (Redis) — el caballo de batalla

Un empleado que tiene los archivos más pedidos sobre el escritorio, al alcance de la mano, en lugar de ir a buscar cada uno al archivo del sótano cada vez.

La mayoría de las apps ponen una cache en memoria dedicada — una herramienta como Redis o Memcached — entre la aplicación y la base de datos. La memoria es muchísimo más rápida que el disco, así que guardar ahí los resultados calientes convierte una consulta lenta a la base de datos en una lectura casi instantánea. Cuando alguien dice "añade una cache" para acelerar un backend, normalmente se refiere a esto.

CDN — la web cacheada cerca del usuario

Libros populares en bibliotecas locales de todas partes, para que nadie tenga que pedirlos por correo a un único archivo central.

Una CDN (content delivery network, red de entrega de contenido) es caching aplicado a la geografía: guarda copias de tus páginas, imágenes y archivos en servidores de todo el mundo (servidores edge), y sirve a cada usuario desde uno cercano. Por eso un sitio global carga rápido en todas partes y no solo cerca de su servidor de origen. Es la misma idea de hit/miss — la copia simplemente se reparte por el mapa para vencer la distancia.

Hit Ratio — la nota que cuenta

A un portero se le juzga por la proporción de tiros que para. Uno que para el 95% lo cambia todo; uno que para el 10% apenas cambia el partido.

El hit ratio es la fracción de peticiones servidas desde la cache en lugar de la fuente lenta. Un hit ratio del 95% significa que solo una de cada veinte peticiones llega a la base de datos — una reducción enorme de carga y latencia. Un hit ratio del 10% significa que la cache es sobre todo sobrecarga. Este único número es como juzgas si una cache funciona.

Cold y Warm Cache — una cache fría tiene que calentarse

Una tienda nueva con las estanterías vacías no sirve rápido a nadie al principio — se abastece según los clientes piden, hasta que los artículos populares están siempre a mano.

Justo después de arrancar, una cache está fría (cold) — vacía, así que cada petición es un miss y va a la fuente lenta. A medida que fluye el tráfico real, se llena de respuestas populares y se vuelve caliente (warm), y el hit ratio sube. Por eso el rendimiento puede verse mal justo después de un reinicio o un deploy, y luego se estabiliza. Algunos sistemas precalientan (pre-warm) la cache a propósito, cargando datos que se sabe que son calientes antes de que lleguen los usuarios.

Memory–Speed Trade-off — una cache cambia memoria por velocidad

Alquilar un escritorio más grande para que quepan más archivos al alcance de la mano — cuesta más espacio, pero vas mucho menos al archivador.

El caching no es gratis: gastas memoria, que es limitada y cuesta dinero, para ahorrar tiempo. Una cache más grande guarda más y acierta más a menudo, pero no puedes cachearlo todo — así que el arte está en cachear las cosas correctas: las respuestas calientes, caras y muy pedidas que dan más velocidad por byte guardado. Una cache es un trade-off deliberado.

Stale Data — el precio del caching

Ese número de teléfono que apuntaste en una nota adhesiva es oro — hasta que tu amigo se muda y la nota, en silencio, pasa a ser incorrecta.

La otra cara de recordar una respuesta es que la respuesta real puede cambiar mientras tu copia no. Un dato stale (obsoleto) es un valor cacheado que ya no coincide con la verdad — el precio viejo, la publicación borrada, el stock de hace una hora. Toda cache corre el riesgo de servir datos obsoletos, y decidir cuánta obsolescencia puedes tolerar es la primera pregunta de diseño real de cualquier cache.

TTL — que caduque con un temporizador

Leche con fecha de caducidad — pasada esa fecha, no te fías sin comprobar, aunque todavía tenga buen aspecto.

La herramienta de frescura más simple es un TTL (time to live, tiempo de vida): cada entrada cacheada recibe una caducidad, y después de ella la entrada se considera eliminada, lo que obliga a traer datos frescos. Un TTL corto significa datos más frescos pero más misses; un TTL largo, más hits pero más obsolescencia. Elegir el TTL es elegir tu punto exacto en el equilibrio entre frescura y velocidad — por tipo de dato, según lo rápido que cambie de verdad.

Cache Invalidation — por qué es famosamente difícil

Saber en el instante exacto en que un dato cambió en otro lugar del mundo, para romper tu nota en el momento justo — fácil de decir, enloquecedor de hacer.

Hay un chiste recurrente según el cual en informática solo hay dos problemas difíciles, y la cache invalidation (invalidación de cache) — saber cuándo hay que tirar un valor cacheado — es uno de ellos. Es difícil porque la cache a menudo no sabe que los datos de origen cambiaron; el cambio ocurrió en otro lugar. El siguiente capítulo reúne las estrategias que se usan contra este problema exacto.

Cache-aside — la app llena la cache

Miras primero tu cuaderno; si está en blanco, vas al archivador, lees el expediente y apuntas la respuesta antes de seguir.

El patrón más común es el cache-aside (también llamado lazy loading, carga perezosa): al leer, la app consulta la cache; en un miss, trae el dato de la fuente, guarda el resultado y lo devuelve. La cache se llena bajo demanda con exactamente lo que de verdad se pide. Es simple y popular — y su punto débil es la obsolescencia, ya que un valor se queda en la cache hasta que algo lo caduca o lo invalida.

Write-through y Write-around — mantener coherentes las escrituras

Cuando un dato cambia, puedes actualizar la nota del escritorio en el mismo momento que el expediente maestro — o saltarte la nota y dejar que se vuelva a traer fresca la próxima vez.

Cuando los datos se escriben, eliges cómo se mantiene al día la cache. Write-through actualiza la cache y la fuente a la vez, así la cache nunca queda obsoleta (a costa de escrituras más lentas). Write-around escribe solo en la fuente y deja que la cache falle y se recargue más tarde, evitando cachear datos que nadie vuelve a leer. Cuál elijas depende de tu mezcla de lecturas y escrituras.

Eviction (LRU, LFU) — decidir qué quitar cuando está llena

Un escritorio pequeño y lleno — para añadir un expediente nuevo tienes que guardar uno, así que quitas el que llevas siglos sin tocar, no el que usas cada hora.

Una cache tiene espacio limitado, así que cuando se llena debe desalojar (evict) algo. La política más común es LRU (least recently used, el menos usado recientemente): quitar lo que lleva más tiempo sin tocarse, apostando a que no hará falta pronto. Existen otras — LFU (least frequently used) quita lo menos usado con frecuencia. El desalojo es cómo una cache pequeña conserva automáticamente los elementos calientes y suelta los fríos, sin crecer para siempre.

Cache Stampede — cuando caduca una clave caliente

Un artículo popular se agota, y en el instante en que ocurre, cien clientes corren al mostrador a pedirlo a la vez — desbordando al único empleado que repone.

Cuando caduca una entrada cacheada popular, todas las peticiones que la querían fallan en el mismo momento y golpean juntas la fuente lenta — un cache stampede (o thundering herd, estampida). La base de datos, protegida durante horas, recibe de golpe a toda la multitud y puede ceder. Las soluciones se conocen — dejar que una petición refresque mientras las demás esperan, o escalonar las caducidades — pero hay que anticiparlo: un stampede aparece justo cuando el tráfico es más alto.

Stale Reads — rápido, seguro de sí y equivocado

Leer un precio de una nota adhesiva vieja y citarlo con seguridad — el número llega al instante, y es el número equivocado.

Una cache sirve con gusto un valor obsoleto rápido y con total seguridad — una stale read (lectura obsoleta). Normalmente no pasa nada — un contador de visitas algo viejo no daña a nadie. Pero con datos donde la corrección es crítica — el saldo bancario, el inventario, los permisos — una lectura obsoleta puede ser un fallo real. La habilidad está en saber qué datos toleran la obsolescencia y cuáles deben estar siempre frescos, y no cachear sin cuidado los segundos.

What Not to Cache — algunas cosas no deberían cachearse nunca

No guardas una fotocopia de un documento que se reescribe cada minuto, ni de la carta privada de alguien en un escritorio compartido — la copia es incorrecta, o no debería estar ahí.

No todo pertenece a una cache. Los datos que cambian constantemente dan un hit ratio pobre y obsolescencia frecuente. Los datos sensibles o por usuario corren el riesgo de filtrarse si una cache compartida entrega la copia de un usuario a otro. Y los datos que casi nadie pide solo malgastan espacio. Saber qué no cachear es tan importante como saber qué cachear.

Cache Target — cachear lo caliente, caro y de cambio lento

Memorizas los pedidos habituales de los clientes de siempre y las indicaciones que das diez veces al día — no las peticiones únicas ni lo que cambia por minutos.

El cache target ideal es lo que se lee con frecuencia, es caro de producir y rara vez cambia — esa combinación da la mayor velocidad con el menor riesgo de obsolescencia. Una página popular construida con una consulta lenta y recalculada idéntica todo el día es perfecta. Un valor que cambia constantemente, se lee poco y es sensible es lo contrario.

Staleness Budget — decídelo de antemano

Acordar de antemano cuánto desfase es aceptable — un widget del tiempo puede tener minutos de retraso; un saldo bancario no puede tener segundos.

Antes de cachear nada, decide cuánta obsolescencia tolera — ese es su staleness budget (presupuesto de obsolescencia). Esa decisión condiciona todo lo demás — el TTL, si necesitas invalidación activa, si es seguro cachearlo siquiera. Hazla explícita por tipo de dato. "¿Cuánto se le permite estar equivocado, y durante cuánto tiempo?" es la pregunta que convierte el caching de fuente de fallos misteriosos en un trato controlado y deliberado.

Cómo se conectan los conceptos

Dos platos de una balanza: velocidad en uno, frescura en el otro. Cada concepto de este curso mueve uno de ellos.

Todo el caching es un tira y afloja entre velocidad y frescura. A la izquierda, lo que sube el hit ratio: locality, una cache caliente, un desalojo sensato. A la derecha, lo que mantiene a raya los stale data: el staleness budget fija el TTL, y la invalidación tira lo que es incorrecto. Un TTL corto es más fresco pero acierta menos; en una clave caliente, el mismo TTL puede provocar un stampede.