Solo hay dos cosas realmente difíciles en informática: la invalidación de caché y poner nombres a las cosas
— Phil Karlton, 1997
«A mí me funciona bien. ¿Has probado a vaciar el caché?» — Tu diseñador web, hace cinco minutos.
En 2009, por obra y gracia de un descuido contractual, Made Media se encontró siendo responsable del alojamiento de un sitio web complementario a uno de los programas de televisión más populares del Reino Unido. De hecho, era el sitio más visitado de Channel 4 en el país, en parte porque el programa animaba a la gente a entrar en la web y participar en directo, durante la emisión. Podemos dar fe del tráfico que se genera cuando un médico televisivo muy conocido, en horario de máxima audiencia, señala una página con una galería de ciertas partes del cuerpo y sugiere que igual quieres compararte. La gráfica de ancho de banda tiene que multiplicar por 10 su escala en un segundo. El centro de datos te llama para preguntarte qué narices está pasando.
Era un servidor de aúpa. Probablemente tenía casi tanta potencia de procesamiento como tu móvil hoy.
Por aquel entonces, apenas empezábamos a asomarnos a Amazon Web Services. Lo que sí teníamos era un rack de servidores web en un centro de datos en Mánchester. Podíamos dedicar uno entero a ese sitio. Era un servidor de aúpa. Probablemente tenía casi tanta potencia de procesamiento como tu móvil hoy. No hubo prueba de carga. No hubo plan B.
No sé qué pensábamos que íbamos a hacer, quizás echarle agua al servidor si se prendía fuego.
Lo que hicimos fue leer varios artículos sobre cómo aguantar un ataque de denegación de servicio. Y lo primero de la lista era usar un proxy inverso con caché. 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. De hecho, dos de nosotros nos subimos al coche y condujimos hasta Mánchester por la M6. No sé qué pensábamos que íbamos a hacer, quizás echarle agua al servidor si se prendía fuego.
El sitio aguantó sin problema en ese único servidor, gracias a la magia del caché. En estos tiempos de computación en la nube y escalado horizontal, el caché puede quedar en un segundo plano, pero sigue siendo fundamental para mantener los sitios web en pie.
La verdad es que la mayoría de las páginas web no cambian demasiado. Y cuando lo hacen, suele ser en franjas horarias predecibles. Aunque solo puedas cachear el contenido de una página durante un segundo, eso sigue siendo enorme cuando estás gestionando más de 2.000 peticiones por segundo — como ocurre, por ejemplo, en el momento en que se ponen a la venta las entradas de Ed Sheeran.
La mayor parte de los recursos web son perfectamente cacheables: la página de inicio, un botón de venta, un feed de disponibilidad de asientos, un archivo javascript o un calendario de funciones. Y puedes controlar con bastante precisión cuándo expira el caché: especificando «este contenido es válido durante 60 segundos» o «este estado expira exactamente a las 10:00, cuando este evento salga a la venta». El caché HTTP es, en realidad, el núcleo de la infraestructura de internet. Las tan cacareadas redes de distribución de contenido no son más que una red de servidores de caché de proxy inverso, como Varnish. El problema es que, aunque la mayoría de los desarrolladores web entienden el caché HTTP razonablemente bien, pocas veces se toman la molestia de asegurarse de que funciona como debería, porque es un rollo.
Diseñamos las consideraciones de caché dentro de 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 mezclar contenido altamente cacheable (como la disponibilidad de entradas) con contenido difícil de cachear (como los datos personales de un usuario). Unir esas dos lógicas tiene el efecto secundario de hacer que toda la aplicación sea prácticamente incacheable. Da igual lo sofisticada que sea tu arquitectura de escalado horizontal, porque ya hemos demostrado que el caché puede multiplicar el rendimiento por un factor de al menos 2.000. Aunque tu nube pudiera escalar así de rápido en un segundo — spoiler: no puede —, el coste sería brutal.
Por eso en Made Media diseñamos las consideraciones de caché dentro de la arquitectura de la aplicación, en lugar de añadirlas al final. Complica el desarrollo, pero si el caché rompe el código, significa que hay que repensar ese código. Eso es lo que queremos decir con caché primero, preguntas después.