¿Cuándo NO deberías recurrir a una caché? ¿Cuáles son los riesgos reales de cachear en exceso?

#Cachear es una apuesta, no una ganancia gratuita

Toda caché es una apuesta: que servir datos ligeramente obsoletos y duplicados sale más barato que calcular u obtener la versión fresca cada vez. Esa apuesta suele ser correcta, pero sigue siendo una apuesta, y esta pregunta se hace en entrevistas específicamente para ver si el candidato trata el cacheo como un reflejo por defecto o como una decisión deliberada con costos reales del otro lado de la balanza. La respuesta honesta a "¿debería cachear esto?" es "no automáticamente", y saber cuándo decir que no es una habilidad tan senior como saber construir la caché en primer lugar.

#Los riesgos reales de cachear en exceso

Los datos obsoletos se convierten en un bug de corrección, no solo en una molestia de UX. Una descripción de producto con cinco segundos de antigüedad es inofensiva. Un saldo de cuenta con cinco segundos de antigüedad que permite que se apruebe un retiro contra fondos que ya se gastaron en otro lado es un incidente financiero. Los conteos de inventario durante el checkout, las verificaciones de permisos/roles, los feature flags que controlan un interruptor de apagado, y cualquier cosa que alimente un libro contable son lugares donde "eventualmente consistente" es el modelo de consistencia equivocado, y una caché convierte silenciosamente tu sistema de fuertemente consistente a eventualmente consistente sin que nadie haya tomado esa decisión a propósito.

Depurar se vuelve más difícil, no más fácil. Una caché agrega una segunda fuente de verdad que puede estar en desacuerdo con la primera, y esos desacuerdos son, por construcción, invisibles en el camino normal de la solicitud — la solicitud sigue devolviendo 200 OK, solo que con el cuerpo equivocado. "Funciona después de reiniciar el servicio" y "funciona bien en staging pero mal en producción" son ambos síntomas clásicos de una caché desincronizada con la base de datos, y ninguno aparece en un stack trace. Cada caché que agregas es también una capa de indirección que un futuro ingeniero tiene que aprender antes de poder confiar en lo que realmente devuelve una función.

Con frecuencia es optimización prematura. Cachear una consulta que ya se ejecuta en dos milisegundos porque está respaldada por un índice adecuado no hace que el sistema sea más rápido de ninguna forma que un usuario pueda percibir — solo agrega un componente nuevo que correr, monitorear y eventualmente depurar, a cambio de recortar una latencia que nadie iba a notar. El orden correcto es: medir la latencia real y el volumen de llamadas de la operación, confirmar que en efecto es un cuello de botella, y solo entonces recurrir a una caché — no al revés.

Una caché puede ocultar un bug en vez de arreglarlo. Una página que es lenta porque dispara 200 consultas sin agrupar por solicitud (un clásico N+1) efectivamente se volverá más rápida si cacheas su salida — pero cacheaste el síntoma. El patrón de consulta subyacente sigue siendo malo, va a reaparecer en cuanto la caché esté fría o se invalide, y ahora hay dos problemas que arreglar en vez de uno.

La superficie operativa crece. Una caché es infraestructura: algo que hay que aprovisionar, escalar, asegurar y mantener disponible. Cuando se cae, no solo pierdes la mejora de velocidad — puedes sufrir una "estampida de caché" (también llamada thundering herd o dog-piling), donde cada solicitud que antes golpeaba la caché ahora golpea la base de datos al mismo tiempo, a un volumen para el que la base de datos nunca fue dimensionada, convirtiendo una caída de caché en una caída de base de datos.

La complejidad de invalidación se acumula. Cada consulta adicional que se cachea es una entrada más en el mapa de invalidación: un conjunto más de caminos de escritura que ahora tienen que recordar romper las claves correctas. Esto crece más rápido que linealmente, porque las escrituras rara vez afectan a una sola consulta cacheada — y un camino de invalidación que se olvidó es un bug que solo se manifiesta como "a veces el dato está mal", una de las categorías de bug más difíciles de reproducir y arreglar.

#Cuándo NO recurrir a una caché

#Una mitigación más ligera que vale la pena conocer

Incluso cuando cachear es la decisión correcta, el exceso de cacheo se cuela a través de las propias mitigaciones si se aplican en todas partes por defecto. Técnicas como la coalescencia de solicitudes (solo una solicitud por clave puede ir a calcular el valor mientras las demás esperan) o el stale-while-revalidate (servir el valor viejo de inmediato mientras se refresca en segundo plano) existen específicamente para combatir estampidas de caché y ventanas de obsolescencia — pero recurrir a ellas en cada caché, en lugar de solo en las que de verdad ven contención o requisitos estrictos de consistencia, es el mismo error de optimización prematura, un nivel más arriba.

🧠 Check your understanding
0/2 · 0/2 answered
1. Se agrega una caché delante de un reporte que dos usuarios internos consultan aproximadamente una vez por semana. ¿Cuál es el resultado más probable?
Una mejora drástica en la latencia p99 para esos usuariosInvalidación automática y correcta sin trabajo adicionalUna tasa de aciertos cercana a cero, ya que la entrada casi siempre expira o es desalojada antes de que alguien vuelva a pedirlaUna reducción de la carga sobre la base de datos a nivel de toda la empresa
2. ¿Cuál de estos es el argumento más fuerte para NO cachear un valor?
Una lista corta de códigos de país usada para poblar un desplegableUna página de catálogo de productos leída 10,000 veces por minuto y actualizada dos veces al díaUn leaderboard que solo necesita ser preciso dentro de un margen de cinco minutosUn saldo de cuenta que debe reflejar la transacción más reciente antes de aprobar un retiro