Una solicitud pasa a través de múltiples capas de caché, cada una más cerca del usuario sirviendo más rápido pero almacenando menos. La idea es responder lo más afuera posible (cerca del cliente) y solo pasar al origen cuando nada en las capas superiores puede servir la respuesta.
Browser → CDN → Reverse proxy → App/object cache → OPcache → Database
(closest to user, fastest) (closest to data)
Cache-Control/ETag; los activos a menudo obtienen TTLs largos (días–año) con nombres de archivo hasheados.for each layer outward → inward:
if layer has fresh copy → return it (stop here) // a hit; cheapest possible
else → ask the next layer in // a miss; falls through
origin (app + DB) → does the real work, fills caches on the way back out
Cada capa intercambia frescura por velocidad: las capas externas son más rápidas pero más propensas a estar obsoletas, así que pon TTLs largos + hashing de contenido en cosas verdaderamente estáticas e TTLs cortos + invalidación en las dinámicas.
La mayor parte de la reducción de latencia y carga en una pila web proviene del cacheo en la capa correcta. Saber qué almacena cada capa y su TTL típico te permite colocar un caché donde realmente ayuda, evitar servir datos obsoletos y razonar por qué un cambio no apareció (qué capa sigue sirviendo una copia antigua).
Una biblioteca de preguntas de entrevista de IT con respuestas detalladas — de Junior a Senior.
Donar