¿Cómo funciona el cacheo multinivel — L1 en proceso + Redis L2 + CDN — y por qué apilarlos?
Apilar un caché en proceso, una capa Redis compartida y una CDN convierte un problema de hit rate en tres, cada capa atrapando lo que la anterior dejó pasar.
APRENDE HACIENDOPon a prueba tu intuición3 pasos
¿Cómo funciona el cacheo multinivel — L1 en proceso + Redis L2 + CDN — y por qué apilarlos?
Usa los ejemplos y la explicación de la lección para comprobar tu idea.
Reflexión personal. No se envía a ningún servicio de IA.#La forma del problema: latencia, capacidad y radio de impacto compiten entre sí
Todo caché se ubica en algún punto de un espectro: más cerca del código que necesita el dato (rápido, pequeño, privado) o más cerca del resto del mundo (más lento, enorme, compartido). Ninguna capa es buena en ambos extremos del espectro a la vez, y por eso los sistemas de producción a los que de verdad les importa la latencia apilan varias capas en lugar de elegir una sola.
- L1 — caché en proceso. Un simple mapa en memoria (o una librería como Caffeine en la JVM, un dict LRU en un proceso Node/Python) que vive dentro del mismo proceso que atiende la request. Cero saltos de red — las lecturas cuestan nanosegundos a pocos microsegundos. Pero es privado a una sola instancia, limitado por la memoria de esa instancia, y se evapora en cada reinicio o despliegue.
- L2 — caché compartido (Redis/Memcached). Un almacén lógico único con el que hablan todas las instancias por red. Más lento que L1 (un round-trip, típicamente de menos de un milisegundo a unos pocos milisegundos), pero consistente entre todas las instancias y mucho más grande.
- CDN — caché de borde. Cachea respuestas HTTP completas en puntos de presencia cercanos al usuario final, distribuidos geográficamente. Excelente para cualquier cosa cacheable y no personalizada; inútil para datos autenticados y por-usuario, pero capaz de servir una request sin que tu infraestructura intervenga en absoluto.
- Origen. La base de datos o el cómputo costoso que produce el valor en primer lugar, cuando todas las capas anteriores fallaron.
#Cómo se mueve realmente una request a través de la pila
Un caso concreto donde las tres capas se ordenan legítimamente así: un servicio de precios que lee datos de referencia (tipos de cambio, feature flags, textos de marketing traducidos) publicados por un sistema de contenido upstream que a su vez está detrás de una CDN. El servicio revisa primero su propio L1, cae al L2 compartido en Redis que pueblan todas las instancias de ese servicio, y solo si falla ahí hace una llamada de red real —que llega al borde de la CDN frente al sistema de publicación antes de siquiera tocar la base de datos de ese sistema.
Cada miss que evitas en L1 es un miss evitado en todas las capas detrás de él. Ese efecto compuesto es la razón real para apilar cachés en lugar de simplemente elegir "el mejor": si L1 atrapa el 80% de las requests, L2 solo llega a ver el 20% restante —y si L2 atrapa el 80% de eso, la CDN y el origen ven apenas el 4% del tráfico original. Cada capa solo necesita ser razonablemente buena atrapando lo que se le escapó a la capa de enfrente.
#La frescura se vuelve más difícil de razonar, no más fácil
El costo de este hit rate compuesto es un riesgo de obsolescencia también compuesto. Un valor puede estar simultáneamente "fresco" en la base de datos, invalidado en L2 por el camino de escritura descrito en una lección hermana sobre consistencia con múltiples instancias, y aun así obsoleto en una docena de L1 distintos hasta que expire el TTL de cada uno o le llegue un mensaje de pub/sub. Como regla general, los TTL deberían ser más largos cuanto más lejos esté una capa del camino de escritura y más difícil sea invalidarla directamente:
| Capa | TTL típico | Por qué |
|---|---|---|
| L1 (en proceso) | Segundos a decenas de segundos | Es más barato estar equivocado brevemente; es la más difícil de invalidar en remoto (necesita pub/sub) |
| L2 (Redis) | Minutos | Cualquier escritor puede invalidarla directamente; al ser compartida, un solo delete la arregla para todos |
| CDN | Minutos a horas, o "para siempre" con purga explícita | Purgar es una llamada de API explícita, muchas veces a un tercero; las URLs versionadas evitan el problema por completo |
🧠 Check your understanding
0/2 · 0/2 answered1. ¿Por qué los cachés multinivel suelen usar un TTL más corto en L1 (en proceso) que en L2 (Redis compartido)?
2. ¿Cuál es la razón principal por la que apilar L1, L2 y una CDN reduce la carga sobre la base de datos de origen más que cualquier caché aislado?