¿Por qué ocurren spikes de caché al 100% en API key desha…
La mayoría de los gateways API validan la autenticación después de buscar en caché, no antes. Cuando deshabilitás o revocás una API key, los datos cacheados siguen siendo servidos sin validación, causando picos de caché al 100% donde debería haber rechazo. Esto es un problema de orden de ejecución en el pipeline de request que puede exponer información sensible de keys revocadas.
En 30 segundos
- El spike de caché al 100% ocurre porque la mayoría de gateways chequean caché antes de validar la API key
- Una key deshabilitada sigue sirviendo datos cacheados si no se invalida explícitamente el TTL
- El problema no es de caché sino de order of operations: validación después del cache lookup, no antes
- La solución requiere reordenar el pipeline: key validation → cache lookup → serve response
- Monitorear cache hit rate por key es crítico para detectar keys revocadas sirviendo datos
Qué es la tasa de caché en APIs
La cache hit rate en un API Gateway es el porcentaje de requests que se sirven desde caché sin tocar el backend. Si tu tasa es 70%, significa que 7 de cada 10 requests se resuelven instantáneamente desde el cache, el otro 30% va al servicio real (cache miss). La idea es obvia: menos latencia, menos carga en el backend.
Una tasa normal en producción está entre 40% y 75%, dependiendo de qué tan repetitivos sean los requests. E-commerce con productos estables: 80%. APIs de datos en tiempo real: 20%. Una tasa de 100% (como decís que ves) es anómala. Literalmente, cero requests están yendo al backend (o a validación), todos se sirven desde caché.
El TTL (Time To Live) es lo que controla cuánto tiempo vive un cache entry antes de expirar. TTL de 300 segundos = la respuesta se cachea 5 minutos. Después de eso, el siguiente request hace un miss y trae data fresca. TTL=0 significa “no cachees esto”, expira inmediatamente (ponele que invalida en el acto). TTL infinito = cachea para siempre, hasta que lo borres manualmente.
Por qué ocurren spikes de caché al 100% con API keys deshabilitadas
Acá viene lo bueno: la mayoría de gateways implementan el flujo así:
1) Request llega → 2) Gateway busca en caché → 3) Si hay hit, sirve el response cacheado sin validar nada más → 4) Si hay miss, recién ahí valida la key y va al backend.
Eso significa que si deshabilitás una key pero hay datos cacheados bajo ese key, el gateway sigue sirviendo esos datos sin chequear que la key está revocada (porque nunca llegó a la validación). El resultado: 100% cache hit rate en esa key específica porque cada request golpea caché y sale, nunca llega a backend para que se rechace la validación. Complementá con alternativas locales para evitar dependencias.
Lo interesante es que no es un bug de caché. Es un problema de arquitectura del pipeline — el orden en que se ejecutan las políticas. Si la validación estuviera primero, jamás llegarías a caché (o llegarías con un 403 Forbidden). Pero porque la validación está después, el caché nunca ve que la key fue revocada.
Ponele que tenés una key compartida entre dos microservicios, uno de ellos se compromete, revocás la key en el control plane, pero los datos para ese endpoint estaban cacheados hace 2 horas con TTL=3600. Ese microsservicio comprometido puede seguir leyendo esos datos del caché porque el gateway nunca validó que su key fue revocada. Eso no es poco.
Diferencia entre caché deshabilitada, TTL=0 y revocación de keys
Tres cosas diferentes, tres comportamientos distintos:
| Escenario | Comportamiento | Cache hit rate | Datos servidos |
|---|---|---|---|
| Caché completamente deshabilitada | Todos los requests van directo a backend, sin cache lookup | 0% | Siempre frescos (o rechazados si key está revocada) |
| TTL=0 | Se busca en caché, pero está expirado inmediatamente, siempre miss | 0% | Siempre frescos (o rechazados) |
| Key revocada, caché activa | Se sirven datos cacheados sin validar la revocación | Spike a 100% | Datos viejos de una key que no debería tener acceso |
El tema es que desabilitar caché por completo es costoso (cada request al backend). TTL=0 también (más overhead). Pero revocar una key sin invalidar el caché es peligroso.
Cómo interactúan rate limiting y caching
Son dos mecanismos separados que pueden interferer de formas inesperadas. Rate limiting controla cuántos requests aceptás por unidad de tiempo. Caching controla dónde obtenés la respuesta (caché o backend). Pueden coexistir pero si no están bien orquestados, ves anomalías.
Caso típico: tenés rate limiting activado (máximo 1000 requests/minuto por key) y caché activada (TTL=300). Una key hace 100 requests en 10 segundos, todos al mismo endpoint. Los primeros 10-15 requests hitean en caché, el resto también. Si esos 100 requests estuvieran todos cacheados, jamás se contan contra el rate limit porque nunca tocaron el throttler (está después del cache lookup). Resultado: la key “se saltó” el rate limit por estar toda en caché, lo que debería ser feature pero a veces se ve como bug.
Ojo: algunos gateways aplican rate limiting antes del cache lookup (más seguro), otros después. Si lo hacen después, una key que está cacheada puede saltarse el rate limit. Si lo hacen antes, el rate limit se aplica incluso a cache hits (menos carga en backend pero menos throughput útil).
Monitoreo y diagnóstico de spikes de caché
Para detectar qué está pasando, necesitás medir por key, no global. En AWS API Gateway podés usar CloudWatch metrics: CacheHitCount y CacheMissCount (ambos por stage y método, pero no nativamente por key). Para granularidad por key, necesitás parsear logs de acceso.
Las métricas que importan:
- Cache hit rate = CacheHitCount / (CacheHitCount + CacheMissCount) — si ves 100%, hay algo raro
- Latencia antes/después — si revocás una key pero la latencia se mantiene igual, probablemente está cacheada
- Cache invalidation events — log de cuándo se purgó caché por key (AWS no lo trackea nativamente, hay que instrumentar)
- TTL distribution — ¿cuántas entradas del caché tienen TTL=3600 vs TTL=0? Si ves todas con TTL alto y una key revocada, problema confirmado
En Azure API Management podés usar Policy Tracing y el portal analítico para ver cache hit/miss por policy. WSO2 API Gateway tiene dashboards nativos de caché por endpoint y API key.
Lo que recomiendo: configurá alertas automáticas. Si cache hit rate >= 95% por más de 5 minutos en un endpoint que no es estático, algo se cocinó. Esto se conecta con lo que analizamos en mejores prácticas de seguridad para credenciales.
Soluciones técnicas según el gateway
AWS API Gateway
El problema en AWS es que la validación de API keys (si usás key authorizers) sucede después de la búsqueda en caché. Solución: reordenar el orden de policies. En API Gateway debés usar una secuencia así:
1) API Key Authorizer (valida la key) → 2) Cache lookup (ahora sabés que la key es válida) → 3) Call backend si miss.
Si tu setup actual es al revés (cache primero), tenés que cambiar el cache key builder para que incluya la key validada como parte de la cache key, o integrar el authorizer como parte del flujo antes del cache. AWS no lo hace por defecto porque asume que la caché está “protegida por autorización previa”.
Azure API Management
En APIM, la solución es más clara: definir el orden explícito de policies en la secuencia `inbound`. Tenés que poner:
1) Validate JWT / Check API Key (en inbound, al principio) → 2) Cache lookup (después que está validada). En la sección `backend` configuras que si hay miss, llama al backend. Así garantizás que nadie sin key válida llega a caché.
WSO2 API Gateway
WSO2 separa explícitamente las fases: request → autenticación → autorización → cache lookup → throttling. Si configurás el cache en la fase correcta (después de auth), no tenés este problema. Pero si usás cache policies custom, podés meter la pata. Más contexto en cómo conectar APIs y manejar autenticación.
Mejores prácticas de seguridad con caché y keys revocadas
Nunca, jamás, dejes que datos cacheados se sirvan sin validar que la key que los pide está vigente. Si revocás una key, invalida explícitamente todo lo que fue cacheado con esa key. La mayoría de gateways no lo hace automáticamente.
Regla oro: validación de keys ANTES de cache lookup, no después. Es lo opuesto a lo que hacen por defecto la mayoría. Eso sí, tiene un costo: si validar una key requiere llamar a un auth service remoto, perdés el beneficio de caché. Pero es el trade-off correcto.
Segundo, usa TTLs apropiados según sensibilidad. Datos públicos: TTL=3600. Datos por usuario: TTL=60 o TTL=0. Datos de configuración crítica: TTL=5 como máximo. Ojo con caché infinito, salvo que sea realmente estático.
Tercero, cachea la respuesta, no la validación. Algunos gateways cachean “la key es válida” como un dato. Eso es un error. Caché la respuesta del endpoint (datos que no cambian), no la decisión de autorización.
Cuarto, monitorea invalidación de caché. Cuando revocás una key, debería haber un evento que dispare purga de caché para esa key. Si tu gateway no lo hace, implementá un job cron que lo haga (limpieza nocturna, por ejemplo).
Errores comunes en caché y API keys
Asumir que desabilitar una key deshabilita su caché
No lo hace. Revocar una key ≠ borrar todo lo que fue cacheado con esa key. Son dos operaciones separadas. Tenés que hacer ambas. Para más detalles técnicos, mirá auditar acceso a claves y recursos.
Cachear basándose en User-Agent o headers volátiles
Si la cache key incluye un header que cambia cada request (tipo un nonce de seguridad), jamás cacheas porque cada request tiene una key diferente. El resultado parece ser un miss permanente, pero en realidad es que la cache key es inútil.
No tener invalidación explícita de caché en la flow de revocación
Cuando revocás una key, tu código hace un `DELETE /cache/key/{key_id}` en el gateway. Si eso no está en el flujo de revocación automático, jamás se ejecuta. Resultado: key revocada pero caché vigente. (spoiler: eso es exactamente lo que estás viendo con el spike al 100%).
Preguntas Frecuentes
¿Por qué ves 100% cache hit rate si revocaste una key?
Porque el gateway sigue sirviendo datos cacheados sin validar que la key fue revocada. Cada request hace cache hit antes de llegar a la validación. Necesitás reordenar: valida primero, después caché.
¿Es seguro servir datos cacheados de una key revocada?
No. Esos datos no deberían estar accesibles. Si revocaste una key por seguridad, es porque no querés que ese cliente vea nada más. Cachear datos previos y seguir sirviéndolos es una brecha.
¿Cómo invalido la caché cuando revoco una key?
Depende del gateway. AWS: manual con `aws apigateway flush-stage-cache`. Azure: borrar el cache tag de esa key en APIM. WSO2: calling cache invalidation endpoint. Lo importante es que esté automatizado en tu flow de revocación.
¿El rate limiting protege contra esto?
No. Si una key revocada está cacheada, el rate limiting no la alcanza (porque nunca llega al throttler). Necesitás validación de key primero.
¿TTL=0 resuelve el spike de caché?
Sí, porque nada se cachea. Pero es ineficiente (cada request al backend). Es parche, no solución. La solución real es reordenar validación antes de caché.
Conclusión
El spike de caché al 100% en keys deshabilitadas no es un problema de caché, es un problema de arquitectura del pipeline de request. Si validás la key después del cache lookup (como lo hace la mayoría), jamás sabrás que fue revocada. La solución: reordenar. Validación primero, cache lookup después.
Además, implementá invalidación automática de caché cuando revoqués una key. Monitorea cache hit rate por key, no global — un 100% en una key específica es una bandera roja. Y recordá: datos cacheados de una key revocada son datos que no deberían estar accesibles. Tratalo como security incident hasta que lo resuelvas.
