IX. Primero el caché (Pregunte después)

"A mí me parece que está bien. ¿Has probado a vaciar la caché?" - Tu diseñador web, hace cinco minutos.

En 2009, debido a un descuido contractual, Made Media recibió la responsabilidad de alojar un sitio web complementario para uno de los programas de televisión más populares del Reino Unido. De hecho, dicho sitio web era el más popular de Channel 4 en el Reino Unido, en parte porque el programa dirigía a la gente al sitio web, y se retroalimentaba de él, en directo. Podemos dar fe del tráfico que se genera cuando un popular médico de la tele, en horario de máxima audiencia, señala una página web con una galería de determinadas partes del cuerpo y sugiere que quizá quieras entrar en Internet para compararte. El gráfico del ancho de banda tiene que multiplicar por 10 su eje de escala en un segundo. El centro de datos te llama por teléfono para saber qué está pasando.

Era un servidor increíble. Probablemente tenía casi tanta capacidad de procesamiento como tu teléfono de hoy.

Por aquel entonces, apenas nos habíamos iniciado en Amazon Web Services. Lo que sí teníamos era un rack de servidores web en un centro de datos de Manchester. Podríamos dedicar uno de ellos a este sitio web. Era un servidor badass. Probablemente tenía casi tanto poder de procesamiento como su teléfono hoy. No había prueba de carga. No había plan de respaldo.

No sé qué pensábamos hacer, tal vez echar agua sobre el servidor si se incendiaba.

Lo que hicimos fue leer algunos artículos sobre cómo resistir un ataque de denegación de servicio. Y el número uno de la lista era usar un Proxy Caché Inverso. El de código abierto que todo el mundo recomendaba se llamaba Varnish. Lo instalamos, hicimos algunas optimizaciones en la configuración del servidor web y cruzamos los dedos. En realidad, dos de nosotros condujimos por la M6 hasta Manchester. No sé qué pensábamos hacer, tal vez echar agua sobre el servidor si se incendiaba.

El sitio web funcionaba perfectamente en ese único servidor, gracias a la magia del almacenamiento en caché. En estos días de computación en la nube y aplicaciones de escalado horizontal, el almacenamiento en caché puede pasarse por alto, pero sigue siendo fundamental para mantener los sitios web operativos.

La verdad es que la mayoría de las páginas web no cambian demasiado. Y cuando lo hacen, suelen hacerlo en intervalos de tiempo predecibles. Incluso si solo puedes almacenar en caché la información de una página durante un segundo, sigue siendo una cantidad enorme, cuando haces más de 2.000 peticiones por segundo, como -por ejemplo- en medio de una venta de Ed Sheeran.

La mayoría de los activos web se pueden almacenar en caché, ya sea una página de inicio, un botón de venta, un feed de disponibilidad de asientos, un fragmento de javascript o un calendario de actuaciones. Y puedes controlar, con bastante precisión, cuándo caduca una caché, ya sea especificando "este contenido es válido durante 60 segundos" o "este estado caduca exactamente a las 10:00 de la mañana, cuando este evento sale a la venta". De hecho, la caché HTTP es el núcleo de la infraestructura de Internet. Las tan cacareadas redes de distribución de contenidos no son más que una red de servidores caché de proxy inverso, como Varnish. La cuestión es que, aunque la mayoría de los desarrolladores web tienen un conocimiento razonable de la caché HTTP, a menudo no se esfuerzan en asegurarse de que realmente funciona según lo previsto, porque es un poco pesado.

Diseñamos las consideraciones de almacenamiento en caché en la arquitectura de la aplicación, en lugar de añadirlas al final.

Lo peor que puedes hacer, si eres responsable de una aplicación de alta demanda, es fusionar tu contenido altamente almacenable en caché (como la disponibilidad del rendimiento), con tu contenido difícil de almacenar en caché (como los datos personales de un usuario). Unir estas preocupaciones empresariales tiene el efecto secundario de hacer que toda la aplicación sea en gran medida no almacenable en caché. No importa lo sofisticada que sea su arquitectura de escalado horizontal en estas circunstancias, porque ya hemos demostrado que el almacenamiento en caché puede conseguir beneficios de rendimiento de un factor de al menos 2000. Incluso si tu nube puede escalar tan rápido en un segundo (spoiler - no puede), estarás pagando un dineral por ello.

Por eso, en Made Media diseñamos las consideraciones de caché en la arquitectura de la aplicación, en lugar de añadir la caché al final. Esto dificulta el desarrollo, pero si la caché rompe el código, significa que hay que replanteárselo. Esto es lo que entendemos por "cachear primero, preguntar después".

Lecturas obligatorias

• Varnish un proxy inverso HTTP de caché.
• Fastly una red de distribución de contenidos (CDN).