Caché: la misma respuesta, pedida otra vez

Ya tienes un cliente, un servidor y un contrato entre ellos. Ahora mira qué se le pide de verdad al servidor. Miles de personas distintas piden miles de veces por hora la página de una tienda popular, y la respuesta es idéntica todas y cada una de esas veces. El servidor vuelve a leer las mismas filas de la base de datos, vuelve a armar el mismo JSON y envía los mismos bytes, miles de veces, por un solo dato que cambió esta mañana. Guardar en caché es la decisión de dejar de hacer eso.

La razón por la que la caché funciona no es un almacenamiento ingenioso. Es la forma del tráfico real: las peticiones se repiten. Unos pocos elementos se piden muchísimas veces, y la mayoría casi nunca. Cuando la misma pregunta llega mil veces, hacer el trabajo una vez y quedarse con la respuesta convierte mil trabajos en uno más novecientas noventa y nueve copias. Por eso también la caché a veces falla feo: si cada petición es realmente distinta, como una página personalizada para cada usuario, no hay nada que reutilizar y la caché solo agrega una búsqueda delante del trabajo real.

Las cachés viven en varios niveles, y cada nivel cambia distancia por control. Vale la pena leer la tabla de abajo por columnas: un acierto más cerca del usuario es más rápido y más barato, pero una copia vieja más cerca del usuario también es la más difícil de corregir, porque ya no controlas la máquina que la tiene.

WHERE IT LIVES        WHO SHARES IT    HIT COST     SIZE      LIFETIME
--------------------  ---------------  -----------  --------  ------------------
browser cache         one user         milliseconds smallest  dies with the tab
CDN edge              one city         tens of ms   large     shared by strangers
application cache     one service      under a ms   medium    lives in RAM
database cache        one query        under a ms   large     lives next to the dataEl mismo intercambio en todos los niveles: mientras más cerca del usuario está la copia, más rápido es el acierto y más difícil es quitarla.

La parte difícil tiene nombre: invalidación. Cuando el precio cambia en la base de datos, toda copia guardada del precio viejo pasa a ser una mentira, y el servidor tiene que borrar esas copias o hacer que expiren. Hacerlo bien cuesta trabajo de verdad. Puedes expirar por tiempo: es simple y se equivoca durante una ventana de minutos. Puedes expirar al escribir: es correcto y significa que cada trozo de código que cambia los datos ahora debe acordarse de avisarle a la caché, que es justo el tipo de regla que se olvida en un arreglo de un bug a las 2 de la mañana. No hay opción gratis; solo hay que elegir con qué error puedes vivir.

Así que toda caché encierra una apuesta deliberada: ¿qué tan vieja puede estar esta respuesta? Un logo puede tener un año y nadie lo nota. La foto de un producto, una hora. Un precio, unos segundos. El saldo de un banco, cero: no lo guardes en caché para nada. Fíjate que la frescura es una decisión de producto, no técnica. El ingeniero que elige max-age=60 en realidad está respondiendo a la pregunta "¿sería aceptable que un cliente vea un precio con un minuto de atraso?". Si la respuesta es no, la caché debe corregirse en el momento en que cambia el precio, y ese es un diseño distinto y más caro.