# No calcules lo que puedes recordar Curso exprés sobre caching. 20 conceptos — cache hit y miss, hit ratio, CDN, Redis, TTL, cache invalidation, cache-aside, write-through, LRU, cache stampede y más — cada uno con su nombre en inglés, un diagrama, un ejemplo y una ficha. Del navegador y la CDN a los almacenes en memoria y la CPU. Al final: una hoja de referencia de una página con todos los conceptos. - **Author:** Fedor Chishchin - **Level:** intro - **Reading time:** ~30 minutos de lectura - **Published:** 2026-06-13 - **Source:** https://fedorthinks.com/es/learn/caching-express --- ## 1. Qué es una cache Una cache es una idea sencilla: guarda una copia de una respuesta en algún lugar rápido, para no pagar por producirla dos veces. Entiende esto y toda cache que conozcas será el mismo truco en un lugar distinto. ### 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_. _Diagram: Los básicos arriba, luego seis grupos — los capítulos 2–7 los siguen._ ### 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. _Diagram: La app pregunta primero a la cache. Solo va a la fuente lenta cuando falta la respuesta._ #### Cache (el cuaderno junto al archivador) - **Problema:** El mismo trabajo costoso se hace una y otra vez. - **Idea:** Guardar el resultado en algún lugar rápido y leerlo de ahí. - **Ejemplo:** Una página calculada, el resultado de una consulta a la base de datos, un archivo descargado — guardados en la cache. - **Coste:** Memoria para las copias, y el riesgo de que una copia quede obsoleta. - **Relaciones:** El resto del curso trata de dónde viven las caches y cuándo fiarse de ellas. ### 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. _Diagram: Un hit responde al instante. Un miss va hasta la fuente y guarda el resultado para la próxima vez._ #### Cache hit / miss (encontrado / no encontrado) - **Qué es:** Un hit significa que la respuesta estaba en la cache. Un miss, que no. - **Cómo funciona:** En un miss haces el trabajo lento y pones el resultado en la cache — así la próxima vez es un hit. - **Ejemplo:** Primera visita a una página: un miss y una consulta a la base de datos. Segunda visita: un hit en milisegundos. - **Relaciones:** La proporción de hits es el **hit ratio**, la nota principal de la cache. ### 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. _Diagram: Unos pocos elementos calientes reciben la mayoría de las peticiones; la larga cola casi nunca se pide._ #### Locality (el conjunto caliente) - **Qué es:** Los mismos datos se piden una y otra vez. - **Por qué importa:** Una cache pequeña de elementos calientes atrapa una gran parte de las peticiones. - **Ejemplo:** Una página popular, el perfil del mismo usuario, la misma búsqueda. - **Pega:** Sin repetición — la cache casi no acierta y solo malgasta memoria. - **Relaciones:** La locality es lo que hace posible un **hit ratio** alto. > **La pregunta de encuadre:** "¿Es cara de producir esta respuesta y se pide repetidamente — las dos condiciones que hacen que valga la pena recordarla?" > Una cache guarda una copia rápida de una respuesta costosa. Un hit es leer la nota; un miss es el paseo hasta el archivador. El trabajo es convertir misses en hits. ## 2. Las caches están en todas partes El caching no es una sola cosa en un solo lugar — es un patrón que se repite en cada capa entre un usuario y los datos. Cuanto más cerca está la copia de quien la necesita, más rápida es. ### 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. _Diagram: Una petición va de la cache más cercana hacia fuera. Más cerca es más rápido, pero más pequeño._ #### Cache Hierarchy (capas de caches) - **Problema:** Una sola cache no puede ser cercana, rápida y grande a la vez. - **Idea:** Una cadena de caches: la cercana, pequeña y rápida; la lejana, grande y más lenta. - **Ejemplo:** Navegador → CDN → cache de la app (Redis) → base de datos. - **Coste:** Más lugares donde puede esconderse una copia obsoleta. - **Relaciones:** Las capas son la **CDN**, la **cache en memoria** y las caches de la CPU. ### 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. _Diagram: Redis guarda pares clave → valor en la RAM. La app solo va a la base de datos en disco cuando hay un miss._ #### In-memory Cache (Redis, Memcached) - **Problema:** Las consultas a la base de datos en disco son lentas, y las mismas se repiten. - **Idea:** Guardar los resultados calientes en la RAM, buscados por clave. - **Ejemplo:** La clave `user:42` guarda un perfil; la app lo lee de Redis en lugar de la base de datos. - **Coste:** Un servicio más; la memoria es limitada; las copias pueden quedar obsoletas. - **Cuándo usarlo:** Para acelerar un backend delante de una fuente de verdad lenta. - **Relaciones:** Suele llenarse con el patrón **cache-aside**. ### 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. _Diagram: Los usuarios reciben la copia del edge más cercano. Un edge solo va al origen cuando hay un miss._ #### CDN (red de entrega de contenido) - **Problema:** El servidor está en un solo país, así que los usuarios lejanos esperan por la distancia. - **Idea:** Guardar copias en servidores edge por todo el mundo. - **Ejemplo:** Las imágenes de un sitio se sirven desde una ciudad cercana al usuario, no desde el origen. - **Coste:** Las copias repartidas por el mundo también se quedan obsoletas; hace falta una forma de refrescarlas. - **Cuándo usarlo:** Archivos estáticos, páginas y recursos para usuarios en muchos lugares. - **Relaciones:** Una de las capas de la **cache hierarchy**. > **La pregunta de las capas:** "¿En qué capa — navegador, CDN, memoria de la app, base de datos — debería cachearse esta respuesta, según quién la pide y cuán cerca puedo ponerla de esa persona?" > El caching es un patrón repetido en cada capa: navegador, CDN, almacén en memoria, CPU. Más cerca es más rápido pero más pequeño — y un miss cae hacia la siguiente capa. ## 3. El hit ratio es lo que importa Una cache solo vale su complejidad si de verdad atrapa la mayoría de las peticiones. Un número — el hit ratio — te dice si tu cache se gana el sueldo. ### 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. _Diagram: 95%: una de cada veinte peticiones llega a la base de datos. 10%: la cache casi no atrapa nada._ #### Hit Ratio (proporción de hits) - **Qué es:** hits ÷ (hits + misses) — la proporción de peticiones servidas desde la cache. - **Ejemplo:** 95% — 1 petición de cada 20 llega a la base de datos. 10% — la cache apenas ayuda. - **Por qué:** La principal forma de saber si una cache funciona, y la principal palanca que se ajusta. - **Relaciones:** Sube con la **locality** y un buen **desalojo**; baja con una **cache fría** y un **TTL** corto. ### 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. _Diagram: Tras un reinicio el hit ratio empieza en cero y sube. Una cache precalentada empieza alto._ #### Cold / Warm Cache (precalentamiento) - **Qué es:** Fría — una cache vacía, todo es miss. Caliente — llena, y acierta. - **Ejemplo:** Tras un deploy el sitio va lento unos minutos hasta que la cache se llena. - **Pega:** Reiniciar todos los nodos a la vez manda toda la carga a la base de datos. - **Solución:** **Precalentar**: cargar los datos calientes antes de que lleguen los usuarios. - **Relaciones:** Explica las caídas del **hit ratio** tras los reinicios. ### 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. _Diagram: Pagas en memoria y compras tiempo. El hit ratio te dice si el trato compensa._ #### Memory–Speed Trade-off (memoria por tiempo) - **Idea:** Pagar con memoria para hacer menos viajes a la fuente lenta. - **Ejemplo:** Más RAM para Redis — caben más claves, más hits. - **Coste:** La memoria es limitada y cuesta dinero; no puedes cachearlo todo. - **Cuándo usarlo:** Cachea lo que da más velocidad por byte: lo caliente y lo caro. - **Relaciones:** El **hit ratio** mide el beneficio; el **desalojo** libera el espacio. > **La pregunta del ratio:** "¿Qué proporción de las peticiones sirve realmente esta cache — y es ese ratio lo bastante alto para justificar la memoria que cuesta?" > El hit ratio es la libreta de notas de la cache. Gastas memoria para comprar velocidad — así que cachea las respuestas calientes y caras que ganan más hits por byte. ## 4. Mantenerla fresca Una respuesta recordada puede quedar desfasada mientras sigues fiándote de ella. Saber cuándo dejar de fiarte de la copia es el problema central, y de verdad difícil, del caching. ### 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. _Diagram: El precio cambió en la fuente, pero nadie actualizó la copia cacheada — quedó obsoleta._ #### Stale Data (copia desactualizada) - **Qué es:** Un valor cacheado que ya no coincide con la fuente. - **Ejemplo:** El precio viejo, la publicación borrada, el stock de hace una hora. - **Por qué ocurre:** La verdad cambió; la copia no. - **Relaciones:** Acotado por el **TTL** y la **invalidación**; cuánto es aceptable lo fija el **staleness budget**. ### 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. _Diagram: Mientras no se agota el TTL, la respuesta sale de la cache. Después, la siguiente petición trae datos frescos._ #### TTL (tiempo de vida) - **Problema:** Una copia puede quedar obsoleta y la cache no lo sabe. - **Idea:** Dar a cada entrada una hora de caducidad; pasada, volver a traerla. - **Ejemplo:** Un tipo de cambio cacheado con un TTL de 60 segundos: nunca tiene más de un minuto. - **Coste:** Un TTL corto significa más misses; uno largo, más obsolescencia. - **Cuándo usarlo:** Casi siempre, como red de seguridad base; ajústalo por tipo de dato. - **Relaciones:** Una clave caliente que caduca para todos a la vez causa un **cache stampede**. ### 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. _Diagram: Un servicio cambia la base de datos, otro lee la copia vieja de la cache. ¿Quién avisa a la cache?_ #### Cache Invalidation (tirar la copia) - **Problema:** Los datos cambiaron en otro lugar, y la cache no lo sabe. - **Idea:** Tirar o refrescar la copia cuando la verdad cambia. - **Ejemplo:** Tras un cambio de precio, borrar la clave del producto de la cache. - **Coste:** Hay que encontrar todos los lugares donde vive la copia, sin olvidar ninguno. - **Relaciones:** Estrategias: **cache-aside**, **write-through**, **write-around**; red de seguridad: **TTL**. > **La pregunta de la frescura:** "¿Cuán obsoletos pueden estar estos datos sin peligro — y basta un simple TTL, o necesito tirar la copia activamente cuando la verdad cambia?" > Toda respuesta cacheada puede quedar obsoleta. Un TTL la caduca con un temporizador — y saber exactamente cuándo invalidar es uno de los problemas realmente difíciles de la informática. ## 5. Invalidación y desalojo Dos fuerzas deciden qué hay en una cache y si es de fiar: cómo la actualizas cuando la verdad cambia, y cómo haces sitio cuando se llena. Ambas tienen estrategias con nombre que vale la pena conocer. ### 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. _Diagram: Cache-aside paso a paso: preguntar a la cache → miss → leer la base de datos → guardar en la cache → devolver._ #### Cache-aside (lazy loading) - **Problema:** Necesitas llenar la cache sin saber de antemano qué se va a pedir. - **Idea:** Lo hace la app: consulta la cache, en un miss lee la base de datos y pone el resultado en la cache. - **Ejemplo:** `GET user:42` → miss → `SELECT` a la base de datos → `SET user:42` con un TTL. - **Coste:** Un valor puede estar obsoleto hasta que se agote su TTL o alguien lo borre. - **Cuándo usarlo:** Lo habitual en la mayoría de las caches delante de una base de datos. - **Relaciones:** A menudo va con el **TTL**; en las escrituras se complementa con **write-through**. ### 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. _Diagram: Write-through escribe en la cache y la base de datos a la vez. Write-around escribe solo en la base de datos; la cache se pone al día en un miss._ #### Write-through / Write-around (políticas de escritura) - **Problema:** En una escritura, la cache y la fuente se desincronizan. - **Idea:** Write-through — actualizar cache y base de datos juntas. Write-around — escribir solo en la base de datos. - **Ejemplo:** Un perfil que se vuelve a leer enseguida — write-through. Logs que casi nunca se leen — write-around. - **Coste:** Write-through — escrituras más lentas. Write-around — un miss justo después de la escritura. - **Cuándo usarlo:** Según tu mezcla de lecturas y escrituras. - **Relaciones:** Formas de hacer **cache invalidation** desde el lado de la escritura. ### 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. _Diagram: La cache está llena y llega F. Con LRU, sale B — nadie la ha tocado desde hace más tiempo._ #### Eviction (LRU, LFU) - **Problema:** La cache se queda sin espacio, y siguen llegando datos nuevos. - **Idea:** Quitar lo que menos probablemente se necesite pronto. - **Ejemplo:** LRU — quitar lo que lleva más tiempo sin tocarse. LFU — quitar lo menos usado. - **Coste:** A veces quita lo que está a punto de pedirse — un miss extra. - **Relaciones:** Mantiene alto el **hit ratio** sin aumentar la memoria. No es lo mismo que la **invalidación**: esa trata de datos erróneos, el desalojo trata del espacio. > **La pregunta de la estrategia:** "Cuando los datos de origen cambian, ¿cómo se entera esta cache — y cuando está llena, ¿está quitando de verdad las entradas frías?" > La invalidación decide cuándo un valor cacheado es incorrecto; el desalojo decide qué quitar cuando se acaba el espacio. Cache-aside, write-through, LRU — nombres para esos dos trabajos. ## 6. Cuando el caching muerde El poder del caching viene con filos cortantes. Los fallos clásicos no son exóticos — son predecibles, tienen nombre, y conocerlos es la mitad de evitarlos. ### 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. _Diagram: Una clave caliente caducó — todas las peticiones se lanzan a la vez contra la base de datos. Abajo: las dos soluciones conocidas._ #### Cache Stampede (thundering herd) - **Problema:** Una clave caliente caduca, y todas las peticiones fallan y golpean la base de datos a la vez. - **Ejemplo:** La página de inicio caduca en el pico de tráfico — miles de peticiones la reconstruyen al mismo tiempo. - **Solución:** Una petición refresca mientras las demás esperan; o dispersión aleatoria del TTL (jitter). - **Cuándo pensarlo:** Con toda clave caliente que tenga un **TTL**. - **Relaciones:** Un efecto secundario del **TTL** en datos populares. ### 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. #### Stale Read (servir el pasado) - **Problema:** La cache sirve un valor viejo, rápido y con seguridad. - **Inofensivo:** Un contador de visitas con un minuto de retraso. - **Un fallo real:** El saldo bancario, el inventario, los permisos. - **Solución:** Decidir de antemano qué datos toleran la obsolescencia y cuáles no. - **Relaciones:** Cómo se manifiestan los **stale data**; se trata con un **staleness budget**. ### 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. _Diagram: Tres tipos de datos que no pertenecen a una cache. Abajo: cómo una cache compartida entrega los datos del usuario A al usuario B._ #### What Not to Cache (la lista de exclusión) - **Cambia rápido:** Hit ratio pobre y obsolescencia constante. - **Sensible:** Los datos por usuario y secretos en una cache compartida pueden llegar al usuario equivocado. - **Poco pedido:** Casi nadie lo pide — solo ocupa espacio. - **Relaciones:** La otra cara del **cache target**. > **La pregunta de las trampas:** "¿Qué le pasa a mi fuente lenta en el instante en que caduca una entrada caliente — y hay algo en esta cache que sea demasiado crítico en frescura o demasiado sensible para estar ahí?" > Las mordeduras clásicas del caching tienen nombre: stampedes cuando caduca una clave caliente, stale reads servidas con falsa seguridad, y cachear cosas que nunca deberían estar ahí. ## 7. Usarlo bien El caching es una herramienta potente: enorme velocidad por poca memoria, pagada con el riesgo de servir el pasado. Usado con intención, es uno de los mejores tratos de la informática. ### 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. _Diagram: Las tres condiciones juntas forman el cache target ideal._ #### Cache Target (qué cachear) - **Idea:** Se lee a menudo + es caro de producir + rara vez cambia. - **Ejemplo:** Una página popular construida con una consulta lenta, idéntica todo el día. - **Contraejemplo:** Un valor que cambia constantemente, se lee poco y es sensible. - **Relaciones:** Lo contrario de **what not to cache**; da un **hit ratio** alto. ### 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. _Diagram: A la izquierda, datos que toleran la obsolescencia; a la derecha, datos que deben estar siempre frescos._ #### Staleness Budget (cuán viejo es aceptable) - **Problema:** Sin una decisión explícita, la obsolescencia aparece como fallos misteriosos. - **Idea:** Para cada tipo de dato, decidir de antemano cuán viejo puede ser. - **Ejemplo:** El tiempo — unos minutos están bien. Un saldo bancario — ni un segundo. - **Qué fija:** La duración del **TTL**, si necesitas **invalidación**, si cachear siquiera. - **Relaciones:** La respuesta al riesgo de los **stale data** y las **stale reads**. ### 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**. _Diagram: Fuerzas de velocidad a la izquierda, fuerzas de frescura a la derecha. El presupuesto fija el TTL; el TTL acota la obsolescencia y puede provocar un stampede._ #### Antes de añadir una cache - **¿Son calientes los datos** — se piden con la repetición suficiente para dar un hit ratio real? - **¿Son caros** de producir, de modo que un hit ahorre de verdad un trabajo significativo? - **¿Cuán obsoletos pueden estar** — cuál es el TTL, y necesito invalidación activa? - **¿Qué pasa cuando caduca una entrada caliente** — podría causar un stampede? - **¿Es seguro cachearlos** — sin datos secretos por usuario en una cache compartida? - **¿Cómo sabré que funciona** — estoy midiendo el hit ratio? #### Señales de que cacheas bien - Puedes decir el **hit ratio** de tus caches importantes. - Cada cosa cacheada tiene un **TTL deliberado** ajustado a lo rápido que cambia de verdad. - Nada **por usuario ni secreto** está en una cache compartida por accidente. - Tus claves calientes no harán un **stampede** contra la fuente de golpe al caducar. - Cacheas las respuestas **calientes, caras y de cambio lento** — y dejas el resto. ## Hoja de referencia: los 20 conceptos ### Básicos - **Cache** (el cuaderno): Una copia rápida de una respuesta costosa, para no hacer el trabajo dos veces. - **Cache hit / miss** (encontrado / no encontrado): La respuesta estaba en la cache — o tuviste que ir a la fuente. - **Locality** (el conjunto caliente): Los mismos datos se piden una y otra vez — por eso funcionan las caches. ### Capas - **Cache Hierarchy** (capas de caches): Navegador → CDN → memoria de la app → base de datos. Más cerca es más rápido, pero más pequeño. - **In-memory Cache** (Redis, Memcached): Datos calientes en RAM delante de una base de datos lenta. - **CDN** (red de entrega de contenido): Copias de archivos y páginas en servidores cercanos a los usuarios. ### Hit ratio - **Hit Ratio** (proporción de hits): La proporción de peticiones servidas desde la cache. La nota principal de la cache. - **Cold / Warm Cache** (precalentamiento): Una cache vacía falla en todo; una llena acierta. El precalentamiento la carga por adelantado. - **Memory–Speed Trade-off** (memoria por tiempo): Pagas en memoria, compras tiempo. Cachea lo que da más velocidad por byte. ### Frescura - **Stale Data** (copia desactualizada): La copia ya no coincide con la verdad. - **TTL** (tiempo de vida): La vida útil de una entrada; pasada, se vuelve a traer. - **Cache Invalidation** (tirar la copia): Tirar la copia cuando la verdad cambia. Famosamente difícil. ### Estrategias - **Cache-aside** (lazy loading): La app consulta la cache, lee la base de datos en un miss y guarda el resultado. - **Write-through / Write-around** (políticas de escritura): Escribir en la cache y la base de datos juntas — o solo en la base de datos. - **Eviction (LRU / LFU)** (hacer sitio): Al llenarse, quitar la entrada que lleva más tiempo sin tocarse o la menos usada. ### Trampas - **Cache Stampede** (thundering herd): Caduca una clave caliente — todos golpean la base de datos a la vez. - **Stale Read** (servir el pasado): Rápido, seguro de sí y equivocado. Peligroso con dinero, stock y permisos. - **What Not to Cache** (la lista de exclusión): Cambia rápido, sensible, poco pedido. ### Usarlo bien - **Cache Target** (qué cachear): Se lee a menudo, es caro de hacer, rara vez cambia. - **Staleness Budget** (cuán viejo es aceptable): Decidir de antemano cuán viejos pueden ser los datos. Fija el TTL y la invalidación. > El caching cambia un poco de memoria por una enorme velocidad, con el riesgo de servir el pasado. Bien hecho, es deliberado: las respuestas correctas, con un staleness budget elegido a propósito. Fin del curso exprés · 7 capítulos · 20 conceptos Ahora toca la práctica: encuentra la operación repetida más lenta de algo que hayas construido — una consulta, una llamada a una API, una página calculada — y pon delante una cache pequeña con un TTL explícito. Luego observa cómo cambian el hit ratio y la latencia. El trato se vuelve real en el momento en que lo mides. Pero quédate con una idea por encima de las demás: el caching es simplemente recordar una respuesta costosa en lugar de rehacer el trabajo — y toda parte difícil es en realidad una sola pregunta, hecha con honestidad: ¿cuándo deja de ser verdad lo que recordé?