Spring GDS 25 Aniversario
Una empresa de logística que envía a 190 países construyó algo para enviarse a sí misma.
El caching consiste en guardar el resultado de un trabajo costoso para que la siguiente petición lo reutilice en lugar de rehacerlo. Una consulta a base de datos que tarda 200 milisegundos corre una vez, la respuesta se guarda en algún sitio rápido, y las siguientes mil peticiones la leen en menos de un milisegundo. El trabajo ocurre una vez y rinde muchas.
Las cachés viven en cada capa de un sistema. El navegador cachea recursos para que una visita repetida cargue al instante. Una CDN cachea páginas y archivos cerca del usuario. Un almacén en memoria como Redis cachea resultados de consultas y sesiones. La base de datos cachea sus propias páginas calientes. Cada capa responde a la misma pregunta: ¿puedo evitar volver a hacer este trabajo? La parte famosamente difícil es la invalidación. Una caché guarda una copia, y en el momento en que el dato real cambia, esa copia es una mentira hasta que algo la limpia. Cachea demasiado tiempo y los usuarios ven información obsoleta. Cachea demasiado poco y pierdes el beneficio. La portada de un periódico cachea su lista de artículos durante treinta segundos, así que un millón de lectores en esa ventana dan todos en la caché mientras la página sigue casi en vivo.
Las estrategias habituales incluyen la expiración por tiempo, la invalidación por evento cuando el dato cambia y la revalidación por tags que limpia las entradas relacionadas a la vez.
El caching suele ser la mejora de rendimiento más barata y grande disponible, y el lugar donde se esconden los bugs más feos. Un precio obsoleto, un usuario logueado al que se le sirve la página cacheada de otro, un dashboard mostrando los números de ayer. Por eso diseñamos la historia de la invalidación antes de añadir la caché, no después de que un cliente reporte el bug. Ese pensamiento por adelantado es la diferencia entre un caching que ayuda y uno que corrompe en silencio la confianza en el dato.
Afinamos el caching por capa y por ruta, porque la respuesta correcta para una página de marketing es la equivocada para un saldo de cuenta en vivo. La invalidación por evento y por tags mantiene honesto el contenido cacheado cuando el dato subyacente se mueve. Es una parte recurrente de nuestras pruebas y monitoreo de rendimiento, y atraviesa nuestro desarrollo web y de aplicaciones web a medida siempre que un sistema tiene rutas calientes que merece acelerar.
¿Páginas lentas bajo carga, o te preocupa que una caché sirva datos obsoletos? Vamos a afinar tu estrategia de caching.
Una empresa de logística que envía a 190 países construyó algo para enviarse a sí misma.
Convertir una marca en un negocio que funciona.
Medio millón de personas. Una app. Cero caos.















