La lección anterior dejó el catálogo de Kilómetro Cero en PostgreSQL con jsonb y una promesa: que Redis se pondría delante. Esta lección cumple la promesa y cierra el módulo. Un caché guarda una copia de datos que cuesta obtener (una consulta a la base de datos, una llamada gRPC a inventario, una imagen redimensionada) en un lugar más rápido y más cercano, para no volver a pagar ese coste mientras la copia siga siendo útil. Parece simple, y en su forma básica lo es; lo difícil es todo lo que rodea a "mientras siga siendo útil": cuándo caduca la copia, cómo se invalida cuando el dato cambia, qué pasa cuando miles de peticiones descubren a la vez que ha caducado, qué hacer con la clave que todos piden, y cómo evitar que la caché devuelva algo que la base de datos ya no dice. Veremos los patrones (cache-aside, read-through, write-through, write-behind, refresh-ahead), los problemas clásicos y sus soluciones, la comparación Memcached/Redis, y Redis Cluster con sus 16 384 slots como reencarnación del particionado de 04-01. La práctica pone todo en servicios/catalogo/cache.py, con invalidación por los eventos stock.actualizado de Kafka, y mide la diferencia de latencia con y sin caché durante la "Semana del Queso Artesano".

1. Por qué cachear: latencia y carga en la base de datos
2. Dónde cachear: cliente, CDN, aplicación y caché distribuida
3. Patrones de caché
4. Invalidación y TTL: los dos problemas difíciles
5. Problemas clásicos: stampede, hot keys, penetración
6. Consistencia entre caché y base de datos
7. Memcached frente a Redis
8. Redis Cluster: slots, réplicas y failover
9. Práctica: servicios/catalogo/cache.py y Redis Cluster
10. Errores Comunes y Consejos
11. Ejercicios
12. Conclusión

Cachear responde a dos problemas distintos que suelen aparecer juntos: latencia (la petición tarda demasiado) y carga (el origen no aguanta tantas peticiones). Unos números para sentir la diferencia:

El cálculo de Kilómetro Cero para la "Semana del Queso Artesano": la web sirve 6 millones de vistas de producto al día, concentradas en 12 horas, con un pico de 3 veces la media: unas 420 vistas/s de pico. Cada vista compone la ficha del producto con una consulta al catálogo (producto + productor + fotos + variantes, unos 8 ms en PostgreSQL) y una llamada gRPC a inventario para el stock por mercado (otros 4 ms). Sin caché: 420 consultas/s de 8 ms sobre PostgreSQL (ocupando 3,4 s de CPU por cada segundo: tres o cuatro núcleos solo para el catálogo, y creciendo con la campaña) y 12 ms de latencia mínima por ficha. Pero el catálogo cambia unas 300 veces al día (precios, descripciones, fotos), es decir, una escritura por cada 20 000 lecturas. Con una caché que sirva el 98 % de las vistas, PostgreSQL recibe 8 consultas/s en lugar de 420, y la ficha se compone en menos de 1 ms. La ratio lecturas/escrituras es el primer indicador de que un dato es cacheable; el segundo es cuánta obsolescencia tolera, y el catálogo tolera segundos.

Una petición atraviesa varias capas, y cada una puede cachear:

En la práctica se combinan: una caché local pequeña con TTL muy corto (1–5 s) para las claves más calientes, delante de Redis para todo, delante de la base de datos. Esta lección se centra en la caché distribuida, que es la que resuelve el problema de carga sobre la base de datos de forma compartida entre todas las instancias de catalogo.

Cómo se relacionan la aplicación, la caché y la base de datos define el patrón:

Kilómetro Cero usa cache-aside para el catálogo, con la variante de invalidación por eventos del apartado 6, y refresh-ahead para las 200 fichas más visitadas durante las campañas. El stock, que cambia con cada reserva, no se cachea de la misma forma: la ficha muestra "disponible / pocas unidades / agotado" derivado de un valor con TTL de 10 s, y la reserva real siempre va a inventario; es un ejemplo de que la tolerancia a la obsolescencia se decide por dato, no por servicio.

"Solo hay dos problemas difíciles en informática: la invalidación de cachés y nombrar las cosas" (Phil Karlton). La frase es un chiste porque es verdad: decidir cuándo una copia deja de ser válida exige saber cuándo cambió el original, y en un sistema distribuido nadie tiene esa información completa y a tiempo. Hay dos mecanismos, y se usan juntos:

• TTL (time to live): cada clave caduca a los N segundos. Es simple, robusta (la caché se autolimpia aunque la invalidación falle), y acota la obsolescencia máxima. Su límite: es un compromiso ciego. Un TTL de 5 minutos para el precio de queso-curado significa que la subida de precio puede tardar 5 minutos en verse; uno de 5 segundos significa 12 misses por minuto por clave aunque el precio no cambie en un mes.
• Invalidación explícita: cuando el dato cambia, alguien borra (o actualiza) la clave. Es precisa, pero exige que todos los caminos de escritura la ejecuten (el panel del productor, el importador masivo, el script de corrección que un administrador ejecuta a mano…) y que el borrado llegue (si Redis está inaccesible en ese instante, la clave vieja sobrevive). Con varias cachés (local + Redis + CDN), hay que invalidar en todas.

La combinación práctica: invalidación explícita como mecanismo principal y TTL como red de seguridad, con un TTL lo bastante largo para que los misses sean raros y lo bastante corto para que un fallo de invalidación no dure horas. Para el catálogo de Kilómetro Cero: TTL de 10 minutos e invalidación por eventos.

Una regla derivada: invalidar (borrar) es más seguro que actualizar la caché al escribir. Si dos escrituras concurrentes actualizan la caché en distinto orden que la base de datos, la caché queda con el valor viejo hasta el TTL; si ambas borran, la siguiente lectura recarga el valor correcto. Lo veremos con detalle en el apartado 6.

Cache stampede / thundering herd. La clave producto:queso-curado caduca a las 12:00:00 en plena campaña. En los siguientes 50 ms, 40 peticiones descubren el miss a la vez y las 40 lanzan la misma consulta de 8 ms a PostgreSQL, y las 40 escriben el mismo valor en Redis. Con miles de claves caducando en la misma ventana (porque todas se cargaron juntas al desplegar), la base de datos recibe una avalancha que puede tumbarla, lo que alarga las consultas, lo que acumula más peticiones en miss. Soluciones, que se combinan:

Hot keys. queso-curado en la Semana del Queso Artesano recibe 100 veces más lecturas que el producto medio. En una caché distribuida con particionado (apartado 8), esa clave vive en un nodo, que se convierte en el cuello de botella mientras los demás están ociosos. Soluciones: caché local en cada instancia con TTL corto para las claves calientes (absorbe el 99 % antes de llegar a Redis), réplicas de lectura del nodo que la tiene, o fragmentar la clave (producto:queso-curado:0 … :9 con el mismo contenido, elegidas al azar en lectura, todas invalidadas en escritura) para repartirla en 10 nodos.

Penetración de caché. Un bot (o un enlace roto) pide producto:queso-cuadrado, que no existe. Cache-aside busca en Redis (miss), consulta PostgreSQL (no hay fila) y no escribe nada en la caché porque no hay valor: cada petición de una clave inexistente llega a la base de datos. Con un ataque de un millón de slugs inventados, la caché no sirve de nada. Soluciones: cachear la ausencia (SET producto:queso-cuadrado "" EX 60, un valor centinela con TTL corto) y, para conjuntos de claves enormes, un filtro de Bloom delante: una estructura probabilística compacta que responde "seguro que no existe" o "quizá existe" sin falsos negativos, de modo que las claves que seguro no existen se rechazan sin tocar ni la caché ni la base (Redis lo ofrece con el módulo RedisBloom; Cassandra lo usa internamente para las SSTables, como vimos en 04-04).

La caché es una réplica de la base de datos (03-04) sin ningún protocolo de replicación: la mantiene la aplicación, a mano, y por eso las anomalías son responsabilidad del código. Las dos preguntas son qué hacer al escribir (actualizar o invalidar) y en qué orden.

Considera actualizar la caché al escribir, con dos escrituras concurrentes de precio (A: 15,20; B: 15,90):

Con invalidación (borrar), el mismo entrelazado deja la clave borrada y la siguiente lectura carga 15,90: correcto. Queda el orden entre escribir en la BD e invalidar:

La respuesta habitual es "escribir en BD, luego invalidar", con TTL como red de seguridad y, si el dato es sensible, doble borrado. Y hay una solución estructuralmente mejor, que retoma 02-05: invalidar a partir de los eventos de cambio. inventario ya publica stock.actualizado en pedidos.eventos mediante la tabla outbox, en la misma transacción que el cambio, y ese evento llega seguro (el relay lo garantiza) y llega después del commit (por construcción). Un consumidor de catalogo borra la clave al recibirlo. Con eso:

• La invalidación no depende de que cada camino de escritura se acuerde de borrar: cualquier cambio que pase por la outbox invalida.
• Si Redis está caído cuando llega el evento, el consumidor no confirma el offset y lo reintenta: la invalidación es duradera.
• El orden es siempre "commit, luego invalidar".
• El precio es el retardo del pipeline (decenas de milisegundos, a veces segundos), durante el cual la caché sirve el valor viejo: consistencia eventual con una ventana acotada, aceptable para el catálogo y para el indicador de stock, no para la reserva (que nunca lee de la caché).

Los dos sistemas de caché distribuida más usados se parecen en lo básico (clave-valor en memoria, red, latencia submilisegundo) y difieren en casi todo lo demás:

Kilómetro Cero elige Redis: necesita el lock del stampede (SET NX EX), hashes para las fichas, sorted sets para el ranking de productos más vistos (refresh-ahead), y opcionalmente streams. Y necesitará Redis Cluster cuando una sola instancia no baste.

Un Redis de una sola instancia sirve cientos de miles de operaciones por segundo y decenas de GB; para ir más allá, o para tolerar la caída de un nodo, está Redis Cluster, que es el particionado de 04-01 en su variante de número fijo de particiones:

• El espacio de claves se divide en 16 384 slots. La clave se asigna con slot = CRC16(clave) mod 16384. No hay anillo ni vnodes: hay 16 384 particiones fijas repartidas entre los maestros (con 3 maestros: 0–5460, 5461–10922, 10923–16383).
• Cada maestro posee un rango de slots y tiene una o más réplicas (replicación asíncrona, 03-04). Los nodos se conocen por gossip y comparten el mapa de slots.
• El cliente es informado (opción (c) de 04-01): descarga el mapa de slots y envía cada comando al maestro correcto. Si el mapa está desactualizado, el nodo responde -MOVED 1149 172.22.0.4:6379 y el cliente actualiza y reintenta; durante una migración de slots responde -ASK. redis-py lo gestiona con RedisCluster.
• Hash tags: solo la parte entre llaves se hashea: {queso-curado}:ficha y {queso-curado}:stock:Girona caen en el mismo slot, lo que permite operaciones multiclave (MGET, transacciones, scripts Lua) sobre ellas. Sin hash tag, un MGET de claves en slots distintos falla con CROSSSLOT.
• Failover: si un maestro deja de responder durante cluster-node-timeout (15 s por defecto), la mayoría de los maestros lo declara FAIL y una de sus réplicas se promociona (una elección con época, en la línea de Raft de 03-03). Las escrituras no replicadas aún se pierden: Redis Cluster es AP con ventanas de pérdida, adecuado para una caché, no para datos que no se puedan reconstruir.
• Reequilibrado: redis-cli --cluster rebalance o reshard mueven slots enteros entre maestros, clave a clave con MIGRATE, mientras el clúster sigue sirviendo: el número fijo de particiones de 04-01 en acción.

Como alternativa a Cluster cuando no hace falta particionar, Redis Sentinel vigila un primario con réplicas y hace failover automático sin repartir los datos.

Redis simple en docker-compose.yml para la primera parte:

allkeys-lru hace que, al llenarse los 512 MB, Redis desaloje las claves menos usadas recientemente: comportamiento de caché. appendonly no porque una caché no necesita persistencia.

El módulo de caché (pip install redis). Implementa cache-aside con TTL y jitter, lock contra stampede, cacheo de ausencias y un consumidor de stock.actualizado que invalida:

Lo importante de cada parte:

• obtener es cache-aside con lock por clave: SET lock:<clave> <token> NX PX 3000 solo tiene éxito para el primer proceso; los demás esperan 20 ms y releen. El lock caduca en 3 s por si el dueño muere. _LIBERAR es un script Lua para que "si el token es mío, borra" sea atómico: sin él, un proceso lento podría borrar el lock de otro. (Es un lock de caché: si falla, el coste es una consulta duplicada; un lock de corrección, como el del relay de 03-03, se hace con etcd.)
• La doble comprobación tras adquirir el lock evita que el segundo en llegar recargue lo que el primero acaba de escribir.
• Si la espera supera espera_max, se degrada a consultar el origen directamente sin cachear: mejor una consulta extra que una petición colgada.
• _ttl_con_jitter desincroniza las caducidades; CENTINELA cachea las ausencias contra la penetración.
• El consumidor reutiliza el tópico pedidos.eventos y la envoltura id_evento/tipo/version/fecha_ms/origen/datos de 02-05. enable_auto_commit=False y el commit() después de invalidar hacen la invalidación al menos una vez: borrar dos veces es inofensivo (idempotente), no borrar es el error que queremos evitar. Nótese que las claves de partición de Kafka son el id de pedido, así que los stock.actualizado de un mismo producto pueden llegar por particiones distintas y en distinto orden; como invalidamos (no actualizamos), el orden no importa: es la razón de fondo de la regla "borrar, no actualizar".

Medición de latencia (simulaciones/latencia_cache.py): simulamos la ficha de queso-curado con una "base de datos" que tarda 8 ms y comparamos:

Cuarenta veces menos latencia, y (lo que importa a PostgreSQL) una consulta en lugar de 2 000. Ejecuta después python -c "from servicios.catalogo.cache import *; [invalidar_producto('queso-curado') for _ in range(1)]" desde otra terminal mientras corre la medición con 20 hilos y verás en MONITOR de redis-cli un único SET producto:queso-curado tras cada DEL, con los otros 19 hilos leyendo el valor recién cargado: el lock trabajando.

Redis Cluster con tres maestros y tres réplicas, para la segunda parte. Seis nodos con cluster-enabled yes y un contenedor que los une:

--cluster-replicas 1 asigna una réplica a cada maestro (los tres primeros son maestros, los tres últimos réplicas, emparejados evitando el mismo host cuando es posible). Comprobaciones:

CLUSTER KEYSLOT muestra el CRC16 mod 16384 de cada clave y demuestra que las hash tags entre llaves sitúan claves relacionadas en el mismo slot. La respuesta MOVED sin -c es el mapa de particiones hablando con el cliente. Y CROSSSLOT recuerda que las operaciones multiclave, en una caché particionada, exigen colocalización deliberada.

Failover: docker compose stop redis-1; a los 5 s (cluster-node-timeout), cluster nodes muestra redis-1 como master,fail y su réplica promocionada a master con los slots 0–5460; las escrituras a esas claves siguen funcionando. Al arrancar redis-1, se une como réplica del nuevo maestro. Desde Python:

RedisCluster de redis-py descarga el mapa de slots, enruta cada comando y sigue MOVED/ASK automáticamente: el módulo cache.py funciona sin cambios sustituyendo redis.Redis por RedisCluster, salvo por scan_iter (que recorre todos los maestros) y por las operaciones multiclave, que necesitan hash tags. Una mejora natural del módulo sería nombrar las claves {queso-curado}:producto y {queso-curado}:stock:Girona para poder invalidar todo lo de un producto con un solo DEL multiclave.

• Cachear sin TTL "porque ya invalidamos". La invalidación fallará alguna vez (un camino de escritura olvidado, Redis caído en el instante justo). El TTL es la red de seguridad; ponlo siempre.
• Actualizar la caché al escribir en lugar de invalidar. Dos escrituras concurrentes dejan la caché con el valor equivocado hasta el TTL. Borra; la siguiente lectura carga el valor bueno.
• Invalidar antes de escribir en la base de datos. Ventana grande para cachear el valor viejo. Escribe primero, invalida después; mejor aún, invalida desde los eventos de la outbox.
• Todas las claves con el mismo TTL, cargadas a la vez tras un despliegue. Caducan juntas: estampida. Jitter y, para lo caliente, refresh-ahead.
• Sin cacheo de ausencias. Un bot con slugs inventados atraviesa la caché y llega a la base de datos en cada petición. Centinela con TTL corto o filtro de Bloom.
• Un lock sin caducidad o liberado sin comprobar el dueño. Un proceso muerto bloquea la clave para siempre; un proceso lento libera el lock de otro. NX PX y liberación con script Lua.
• Confundir el lock de la caché con un lock de corrección. El de Redis con SET NX puede fallar en un failover (las escrituras asíncronas se pierden); si de él depende no vender dos veces la última pieza, usa etcd (03-03) o la base de datos.
• Cachear la respuesta de la reserva de stock. El indicador "quedan pocas unidades" puede ir 10 s por detrás; la reserva real nunca lee de la caché. Decide la tolerancia a la obsolescencia por dato.
• Operaciones multiclave en Redis Cluster sin hash tags. CROSSSLOT. Diseña las claves con {tag} desde el principio; cambiarlas después obliga a vaciar la caché.
• Tratar Redis Cluster como base de datos. El failover pierde las escrituras no replicadas. Es una caché (o un almacén reconstruible), y pedidos e inventario viven donde decidió 04-04.

Ejercicio 1. Implementa en cache.py la variante stale-while-revalidate de obtener: guarda en Redis un hash con los campos valor y caduca_logico (marca de tiempo), con TTL físico igual al doble del lógico. Si al leer el valor lógico ha caducado, devuelve el valor viejo inmediatamente y lanza la recarga (en un hilo, protegida por el mismo lock). Explica qué gana la web durante la Semana del Queso Artesano frente a la versión con lock del apartado 9 y qué se pierde.

Ejercicio 2. El evento stock.actualizado se publica en pedidos.eventos con clave de partición = id de pedido. Dos reservas de queso-curado en Girona (pedidos P-2026-000125 y P-2026-000126) generan dos eventos en particiones distintas que el consumidor catalogo-cache puede procesar en orden inverso. Explica (a) por qué la invalidación por borrado es correcta en cualquier orden; (b) qué pasaría si el consumidor en lugar de borrar hiciera SET stock:queso-curado:Girona <disponible del evento>; (c) cómo cambiaría la situación si inventario publicara los eventos de stock con clave = producto, y qué se pierde con ese cambio (pista: 02-04 y la relación con pedido.creado).

Ejercicio 3. Durante la campaña, producto:queso-curado recibe 15 000 lecturas/s y su slot vive en redis-1, que satura (el resto de maestros está al 10 %). Propón dos soluciones combinadas, escribe el código de la fragmentación de la clave en N copias ({queso-curado}:producto:0..N-1) con lectura aleatoria e invalidación de todas, y razona por qué la hash tag {queso-curado} hace que la fragmentación no ayude en Redis Cluster y cómo nombrarías las copias para que sí ayude.

Solución 1:

Lo que gana la web: durante la campaña, ninguna petición de una clave caliente espera a la base de datos (ni siquiera la que dispara la recarga), así que el p99 se mantiene en el submilisegundo de Redis en lugar de saltar a 8 ms cada 10 minutos; y la estampida es imposible porque solo una recarga corre a la vez y las demás sirven el valor antiguo. Lo que se pierde: obsolescencia adicional (el valor viejo se sirve hasta que la recarga acaba, y si el origen falla, hasta el TTL físico), memoria (un hash por clave) y complejidad (hilos en segundo plano, que en un servidor asíncrono se harían con una tarea). Para el precio de una ficha es un buen trato; para el indicador de stock con TTL de 10 s, discutible.

Solución 2:

(a) DEL es idempotente y no lleva valor: da igual cuál de los dos eventos se procese primero, el resultado final es "la clave no está", y la siguiente lectura la recarga desde inventario, que tiene el valor correcto (disponible después de ambas reservas). La invalidación convierte un problema de orden en un problema de existencia, que no tiene orden.

(b) Con SET <disponible del evento>, si el evento de P-2026-000126 (disponible = 1) se procesa antes que el de P-2026-000125 (disponible = 2), la caché acaba en 2 mientras el stock real es 1: incorrecta hasta el TTL de 10 s. Sería necesario comparar fecha_ms o una versión y descartar eventos antiguos (el patrón last-writer-wins de 03-04, con sus riesgos de reloj de 01-05), que es más código y más fallos que un DEL.

(c) Con clave = producto, todos los stock.actualizado de queso-curado irían a la misma partición y llegarían en orden (02-04), y entonces SET sería seguro. Pero se pierde la colocalización con los demás eventos del pedido: pedido.creado, stock.reservado y pago.confirmado de P-2026-000125 dejarían de estar en la misma partición que su stock.actualizado, y los consumidores que reconstruyen la historia de un pedido en orden (la saga por coreografía de 03-05, analitica) perderían esa garantía. Alternativa limpia: un tópico separado inventario.stock con clave = producto para los eventos de stock, que es lo que haría un diseño maduro; mientras tanto, el DEL funciona con cualquier clave.

Solución 3:

Soluciones combinadas: (1) una caché local en cada instancia de catalogo (cachetools.TTLCache(maxsize=500, ttl=2)) para las claves más leídas, que absorbe la inmensa mayoría de las 15 000 lecturas/s antes de llegar a Redis, e invalidada también por el consumidor de eventos (cada instancia consume con su propio group_id, o se publica un PUBLISH de Redis a todas); (2) fragmentar la clave en N copias para repartirla entre maestros:

Con la hash tag {queso-curado} todas las copias tendrían el mismo slot (solo se hashea lo que hay entre llaves) y por tanto el mismo maestro: se repartiría la carga entre claves, no entre nodos, que es justo lo que no sirve. Sin hash tag (producto:queso-curado:c0…c7), CRC16 de cada nombre completo cae en slots distintos y, con alta probabilidad, en maestros distintos; se puede comprobar con CLUSTER KEYSLOT y ajustar los sufijos hasta que las 8 copias cubran los 3 maestros. El coste: 8 misses en lugar de 1 tras cada invalidación (irrelevante con 300 cambios al día) y 8 DEL por invalidación, que ya no puede ser multiclave (van a slots distintos); las réplicas de lectura de Redis Cluster (READONLY en el cliente) son la tercera opción, que reparte lecturas del mismo slot entre maestro y réplica sin cambiar las claves, a cambio de leer con retraso de replicación.

Una caché distribuida es una réplica de conveniencia mantenida a mano por la aplicación, y por eso concentra en el código todos los problemas de replicación que las bases de datos resuelven por protocolo. Cachear compensa cuando la ratio lecturas/escrituras es alta y el dato tolera cierta obsolescencia, como el catálogo de Kilómetro Cero con 20 000 lecturas por escritura: la medición ha bajado la ficha de queso-curado de 8 ms a 0,2 ms y ha quitado a PostgreSQL el 98 % de las consultas de la Semana del Queso Artesano. Hemos situado la caché en sus capas (cliente, CDN, local, distribuida), recorrido los patrones (cache-aside como elección, refresh-ahead para lo caliente, write-through y write-behind para otros casos), y tratado la invalidación con la regla "TTL como red, invalidación explícita como mecanismo, borrar en vez de actualizar, después de escribir en la base de datos". Contra la estampida: lock por clave con token y script Lua, coalescing, jitter y recarga anticipada; contra las claves calientes: caché local, réplicas y fragmentación; contra la penetración: centinelas y filtros de Bloom. La invalidación por los eventos stock.actualizado de pedidos.eventos ha convertido la outbox de 02-05 en el mecanismo de coherencia entre inventario y la caché de catalogo, duradero y correcto en cualquier orden. Redis ha ganado a Memcached por sus estructuras y sus locks, y Redis Cluster ha cerrado el círculo con el módulo: 16 384 slots fijos, MOVED como mapa de particiones en manos del cliente, hash tags para colocalizar, réplicas y failover asíncrono que lo hacen adecuado como caché y no como base de datos.

Con esta lección se cierra el Módulo 4, y cada dato de Kilómetro Cero tiene ya su sitio:

Los datos están repartidos entre muchos nodos y sabemos por qué cada uno está donde está. La pregunta que sigue es cómo procesarlos en masa ahora que ya no caben en una máquina: cómo calcular las ventas de la Semana de la Vendimia por productor y mercado sobre los cientos de millones de eventos del lago, cómo entrenar recomendaciones con los clics de un año, cómo alimentar en tiempo real el panel de reparto. Es el terreno del Módulo 5, la computación distribuida, que empieza por los modelos de computación distribuida: qué significa repartir un cálculo, y no solo un dato, entre muchos nodos.