¿Qué es el Caching de API?

¿Qué es el caching de API?

El caching de API es la práctica de almacenar respuestas de una API para que peticiones idénticas posteriores puedan servirse desde el caché en lugar de re-ejecutar el trabajo subyacente. La respuesta cacheada usualmente está lo suficientemente fresca — para muchos endpoints, los datos cambian con mucha menos frecuencia que se leen — y servir desde caché es dramáticamente más rápido que recalcular desde bases de datos o servicios downstream. El caching es una de las optimizaciones de mayor palanca en ingeniería de API: un caché bien colocado puede recortar la latencia p95 en 10-100x y reducir la carga del backend en 90%+.

Las ubicaciones de caché se apilan: navegador → CDN → API gateway → memoria de aplicación → caché distribuido (Redis/Memcached) → caché de consultas de base de datos. Cada capa recorta una fracción de las peticiones, con tasas de hit progresivamente más altas y costo más bajo a medida que te mueves hacia el usuario. Una estrategia efectiva de caching de API elige la capa correcta (o capas) para cada endpoint basándose en patrones de acceso y requisitos de frescura.

Las cinco principales capas de caching de API

1. Caché del cliente / navegador

El navegador almacena respuestas basándose en headers HTTP cache-control. Cero round trip cuando está cacheado. Mejor para contenido seguro de cachear localmente por usuario (assets estáticos, datos de referencia públicos). Controlado por Cache-Control: max-age=3600 y ETags.

2. Caché de edge CDN (Cloudflare, CloudFront, Fastly)

Cacheado en POPs edge cerca de los usuarios. Tiempo de respuesta ~10-50ms globalmente. Mejor para contenido cacheado para muchos usuarios (APIs públicas, datos anonimizados, endpoints de marketing). Controlado por headers Cache-Control + reglas de caché específicas del CDN.

3. Caché de API gateway (AWS API Gateway, Kong, Apigee)

Caché centralizado frente a tus APIs. Reduce hits del backend sin cooperación del navegador/CDN. Útil para lógica compartida antes de enrutar a servicios.

4. Caché a nivel de aplicación (in-process o distribuido)

El más flexible: cachea cualquier cosa en memoria (in-process) o en Redis/Memcached (compartido entre instancias). Mejor para respuestas computadas que no vale la pena empujar al CDN. Patrón común: cachea la consulta de lectura cara, no la respuesta HTTP completa.

5. Caché de consultas de base de datos

Muchas bases de datos cachean planes de consulta y resultados frecuentes internamente. Menos control pero a menudo automático. shared_buffers de PostgreSQL, query cache de MySQL (deprecado post-8.0), Redis como capa de caché de base de datos.

Headers de caching HTTP (el estándar)

RFC 9111 define la semántica de caché que cada CDN, navegador y reverse proxy sigue:

• Cache-Control: public, max-age=3600 — cacheable por cualquiera durante 1 hora.
• Cache-Control: private, max-age=300 — solo el navegador del usuario puede cachear (no CDN), 5 minutos.
• Cache-Control: no-store — nunca cachear (datos sensibles).
• Cache-Control: no-cache — debe revalidar antes de reusar (cacheado pero condicional).
• Cache-Control: stale-while-revalidate=60 — sirve stale hasta 60s extra mientras obtiene fresh en segundo plano. Gran victoria UX.
• ETag: "abc123" — huella digital del contenido. Cliente envía If-None-Match: "abc123"; servidor responde 304 si no cambió.
• Vary: Accept-Encoding, Authorization — la clave de caché incluye estos headers (contenido diferente por encoding/usuario).

Estrategias comunes de caching

• Cache-aside (lazy loading). La app verifica el caché; en miss, obtiene de la fuente y rellena el caché. Simple, común.
• Read-through. La capa de caché obtiene transparentemente en miss. Menos código de app; requiere que el caché conozca la fuente.
• Write-through. Las escrituras van al caché + fuente simultáneamente. El caché siempre es consistente pero escrituras más lentas.
• Write-back. Las escrituras van al caché; la fuente se actualiza async. Escrituras rápidas pero riesgo de pérdida en fallo de caché.
• Refresh-ahead. El caché refresca proactivamente antes de que el TTL expire. Latencia suave, requiere buena predicción.

Invalidación de caché: el problema difícil

La cita de Phil Karlton es famosa: "Solo hay dos cosas difíciles en ciencias de la computación: invalidación de caché y nombrar cosas." Estrategias:

• Basada en TTL. Establece Cache-Control max-age. Simple. Trade-off: datos obsoletos hasta TTL después del cambio.
• Purge manual. Llama a la API de CDN/caché para invalidar claves específicas cuando los datos cambian. Preciso; requiere que las escrituras sepan qué claves.
• URLs versionadas. Anexa versión (/api/products?v=42) para que los cambios obtengan URLs frescas. Las entradas de caché viejas mueren naturalmente.
• Invalidación impulsada por eventos. Pub/sub difunde "producto 42 cambió"; las capas de caché escuchan y purgan. Más preciso; más complejo.
• Surrogate keys (Cache tags). Etiqueta respuestas con claves lógicas ("user:42", "products") y purga por etiqueta. Fastly, Cloudflare Enterprise lo soportan.

Errores comunes de caching de API

• Cachear respuestas autenticadas públicamente. Los datos de un usuario con sesión iniciada terminan en un caché compartido; otro usuario los ve. Siempre establece Cache-Control: private para respuestas personalizadas.
• Olvidar headers Vary. El caché devuelve respuesta gzipped a un cliente solicitando encoding identity. Siempre incluye Vary: Accept-Encoding.
• TTL demasiado largo. Horas de datos obsoletos después de cada actualización. Ajusta TTL a tu frecuencia de cambio real.
• TTL demasiado corto. Tasa de hit de caché <50% significa que realmente no estás cacheando. Apunta a 90%+ tasa de hit en endpoints cacheados.
• Cache stampede. Cuando el TTL expira, 1,000 peticiones concurrentes todas miss y golpean la base de datos. Mitiga con locks ("solo un fetch en miss"), refresh-ahead, o stale-while-revalidate.
• Cachear errores. Un error 500 se cachea durante 5 minutos; los usuarios siguen viendo la respuesta rota. Siempre establece Cache-Control: no-store en respuestas de error.
• Sin observabilidad. Sin métricas sobre tasa de hit, tasa de miss, y carga de origen, no puedes ajustar. Rastrea estas por endpoint.

FAQ: Caching de API

¿Cómo sé qué cachear?

Perfila tu API: ¿qué endpoints son los más lentos? ¿Más solicitados? ¿Tienen datos estables? Esos son candidatos a caching. Herramientas como Datadog APM muestran latencia de endpoint y tasa de petición lado a lado.

¿Cuál es una buena tasa de hit de caché?

Para endpoints bien cacheados, apunta a 90%+ tasa de hit en el CDN. Más bajo significa que los TTLs son demasiado cortos o estás cacheando cosas que no deberías (datos por usuario). Por debajo del 50% significa que el caching apenas está ayudando.

¿Puedo cachear peticiones POST?

Generalmente no — la semántica HTTP trata los POSTs como cambiantes de estado. Algunas APIs cachean POSTs idempotentes (p.ej., búsqueda) en la capa de aplicación con claves de caché explícitas, pero el CDN no hará esto por ti.

¿Cómo interactúa el caching de API con la limitación de tasa?

Los hits de caché típicamente eluden los límites de tasa (no alcanzan el endpoint con límite de tasa). Esto protege backends pero significa que usuarios abusivos pueden martillar un endpoint cacheado libremente. Para endpoints sensibles, limita la tasa en el edge del CDN.

¿Qué hay sobre el caching GraphQL?

Más complicado que REST. La consulta está en el body POST, así que el caching basado en URL falla. Soluciones: consultas persistidas (convierte consultas complejas en IDs, cacheables como GET), automatic persisted queries de Apollo, hints de caché a nivel de consulta.

¿Cómo pruebo el caching de API?

Funcionalmente: envía peticiones idénticas, verifica que la segunda es más rápida (header X-Cache: HIT, latencia más baja). Bajo carga: prueba de carga con caché habilitado vs. deshabilitado para medir protección del backend.

¿Cuál es la diferencia entre caching y CDN?

Un CDN es una red de entrega con cachés en POPs edge. "Caching" es la práctica más amplia de almacenar respuestas en cualquier capa. El caching CDN es un caso específico.

Cómo se relaciona LoadFocus con la estrategia de caching de API

El valor del caching de API solo se muestra bajo tráfico concurrente realista. Las pruebas de carga de API LoadFocus miden la tasa de hit del backend (cache miss = tráfico golpeando tu origen) bajo concurrencia realista, sacando a la luz cache stampedes y TTLs ineficaces. La monitorización de API rastrea la tasa de hit del caché a lo largo del tiempo para que atrapes regresiones cuando un despliegue accidentalmente eluda el caché.