Un martes por la mañana, la API de Tienda Aroma empieza a responder en cuatro segundos. No hay despliegue nuevo, no hay error en los logs, la base de datos no está caída. Mirando el tráfico aparece el culpable: una única dirección IP haciendo 400 peticiones por segundo a GET /v1/cafes?limite=100, recorriendo el catálogo entero cada pocos segundos. No es un ataque sofisticado: es alguien copiando el catálogo, o —igual de probable— un cliente con un useEffect mal escrito que reintenta en bucle sin esperar.

La API está autenticada, autorizada y endurecida. Y aun así, cualquiera puede tumbarla simplemente llamándola mucho. Esta lección cierra la última fila abierta del modelo de amenazas de 04-02: API4, consumo ilimitado de recursos. Veremos por qué toda API pública necesita límites, los cuatro algoritmos clásicos con sus compromisos, qué se usa como clave de agrupación, la respuesta 429 con sus cabeceras, la implementación en el proyecto con express-rate-limit y Redis, las demás defensas de disponibilidad, y qué debe hacer un cliente bien educado cuando le dicen que pare.

Advertencia. El rate limiting es una defensa de disponibilidad y, mal ajustado, puede negar el servicio a usuarios legítimos o dejar pasar un ataque. Los valores de esta lección son un punto de partida razonable para un caso ficticio; un despliegue real debe dimensionarlos con datos propios y revisarlos con un profesional de seguridad.

1. Por qué toda API pública necesita límites
2. Rate limiting, throttling y cuotas
3. Los cuatro algoritmos
4. Implementación comentada del cubo de fichas
5. La clave: contra qué se cuenta
6. El problema de la IP: NAT, proxies y trust proxy
7. Límites por endpoint
8. Los niveles de Tienda Aroma
9. La respuesta 429 y sus cabeceras
10. Implementación: src/middleware/limite-peticiones.js
11. Almacén en memoria frente a Redis
12. Otras defensas de disponibilidad
13. 503, Retry-After y servicio_no_disponible
14. Qué hace un cliente bien educado
15. Cómo se comunican los límites en la documentación
16. Dónde vive el rate limiting en producción
17. Pruebas del límite con node:test

Los motivos son cinco y conviene distinguirlos, porque cada uno pide un límite distinto:

El tercero merece un matiz importante: la mayoría del tráfico abusivo no es malicioso. Es un desarrollador que no ha visto que su reintento no tiene espera, una app móvil que refresca en cada scroll, un cron que se solapa consigo mismo. Eso cambia el diseño de la respuesta: el 429 tiene que ser pedagógico, decir cuándo volver y ser fácil de manejar programáticamente, porque su destinatario habitual es alguien que quiere arreglarlo.

Y hay un motivo transversal que los engloba: proteger la base de datos. Tu API puede escalar a más instancias; el SQLite de Tienda Aroma, o el PostgreSQL que venga después, no tanto. El rate limiting es lo que impide que un pico de tráfico se traduzca en una avalancha de consultas que deja al resto de consumidores sin servicio.

Tres términos que se usan como sinónimos y no lo son:

• Rate limiting: «100 peticiones por minuto». La 101 se rechaza.
• Throttling: «como máximo 10 peticiones concurrentes». La 11 espera en cola. Es más amable con el cliente pero consume recursos tuyos mientras espera, y puede degradar todo el sistema si la cola crece: por eso siempre necesita un tope de cola y un timeout.
• Cuota: «50.000 peticiones al mes en el plan gratuito». Es un concepto comercial más que técnico; se muestra en la factura, no en cada respuesta.

Tienda Aroma usa rate limiting como mecanismo principal, con una cuota diaria para el socio RápidoEnvíos. El throttling aparece de forma natural en un sitio: el pool de conexiones a la base de datos, que ya limita la concurrencia real.

Se cuenta cuántas peticiones hay en el minuto actual; al cambiar de minuto, el contador vuelve a cero.

Es trivial de implementar y muy barato: un entero por clave. Su problema es el efecto de borde:

El doble del límite en un instante. Con límites generosos es asumible; para proteger un login, no.

Se guarda la marca de tiempo de cada petición y se cuentan las de los últimos 60 segundos, exactamente. Es preciso al 100 % y no tiene efecto de borde. El coste es la memoria: con un límite de 1.000 por minuto y 50.000 claves activas, son 50 millones de marcas de tiempo.

El compromiso práctico. Se guardan dos contadores —el de la ventana actual y el de la anterior— y se estima el valor deslizante por interpolación:

Con dos números por clave se elimina prácticamente el efecto de borde. Es lo que usan la mayoría de las implementaciones serias, incluida Cloudflare.

Un cubo con capacidad C que se rellena a R fichas por segundo. Cada petición consume una ficha; si no hay, se rechaza.

Su gracia es que permite ráfagas de forma controlada: un cliente que ha estado callado acumula fichas hasta C y puede gastarlas de golpe, pero su tasa sostenida nunca supera R. Eso encaja muy bien con el tráfico real de una API: una app que abre una pantalla hace ocho peticiones seguidas y luego calla un minuto, y no queremos castigarla.

Las peticiones entran en una cola que se vacía a ritmo constante. Suaviza el tráfico de salida por completo, pero no permite ráfagas y añade latencia: es throttling, no rate limiting. Se usa más para regular la salida hacia un sistema aguas abajo (por ejemplo, las llamadas a la pasarela de pago) que para la entrada.

La elección de Tienda Aroma: cubo de fichas para el límite general —porque el tráfico de la SPA y de Aroma Móvil es naturalmente a ráfagas— y ventana deslizante estricta para POST /v1/sesiones, donde no queremos ninguna ráfaga.

Cuatro detalles que hacen que esto funcione y que casi siempre se hacen mal:

La recarga perezosa (paso 1) es la idea clave. Un cubo por cliente con un setInterval cada uno sería inviable con miles de claves; calcular las fichas al consultarlas da el mismo resultado con coste constante.

Math.min(capacidad, ...) impide que un cliente inactivo durante un día acumule 86.400 fichas y descargue la base de datos entera de golpe. El máximo acumulable es la capacidad, y por eso la capacidad es el tamaño de ráfaga permitido.

El coste parametrizable (paso 2) abre la puerta al coste por consulta del apartado 12: una búsqueda cara puede consumir cinco fichas en vez de una.

La limpieza (paso 4) es un requisito de disponibilidad, no una optimización: sin ella, un atacante que rote direcciones IP hace crecer el Map hasta agotar la memoria del proceso. Y unref() evita que el temporizador mantenga vivo el proceso al apagarlo, algo que rompería el apagado ordenado de 03-07 y las pruebas de 03-08.

Un límite siempre se aplica a un grupo. Elegir mal la clave es el error más caro:

La regla de selección de Tienda Aroma, en orden de preferencia:

El caso 1 merece explicación: si CataBox tiene un bug y machaca la API en nombre de 500 usuarios, limitar por usuario no detiene nada —son 500 claves distintas—. La clave compuesta permite aplicar además un tope agregado por client_id, que es lo que realmente protege.

Limitar por IP tiene tres problemas serios que hay que conocer antes de fijar un número:

NAT. Una oficina, una universidad o un operador móvil pueden presentar cientos o miles de usuarios detrás de una única IP pública. Un límite de 60 por minuto por IP deja sin servicio a toda una empresa cuyos empleados usen la tienda. Por eso el límite anónimo debe ser generoso, y el estricto reservarse para lo autenticado o para operaciones concretas.

IPv6. Un atacante con un prefijo /64 dispone de billones de direcciones. Limitar por IPv6 individual es inútil: hay que agrupar por prefijo (habitualmente /64).

Proxies. Este es el que rompe el código. Si tu API está detrás de un balanceador o una CDN —y en producción lo estará—, req.ip es la IP del proxy, no la del cliente. Todo el tráfico comparte clave y el primer usuario agota el límite de todos.

La IP real llega en X-Forwarded-For, una cabecera con la cadena de saltos:

Y aquí está la trampa: esa cabecera la puede escribir cualquiera. Un atacante manda X-Forwarded-For: 1.2.3.4 y, si confías ciegamente, cambia de identidad en cada petición y anula el límite.

El número debe coincidir exactamente con la cantidad de proxies que hay delante. Si pones 1 y hay dos (CDN + balanceador), obtienes la IP del primer proxy en lugar de la del cliente; si pones 2 y hay uno, obtienes la IP que el cliente quiera. Compruébalo en el entorno real antes de fiarte:

Recuerda además que este mismo ajuste afecta a req.protocol y por tanto a las cookies Secure y a las redirecciones HTTPS de 04-02: es una configuración con consecuencias más allá del rate limiting.

Un límite global uniforme es siempre un mal compromiso: demasiado laxo para el login, demasiado estricto para el catálogo. Los límites se ajustan al coste y al riesgo de cada operación.

El caso del login merece una precisión importante: hay que limitar por dos claves a la vez.

• Por IP: frena a quien prueba miles de contraseñas contra muchas cuentas desde un sitio.
• Por correo de destino: frena el credential stuffing distribuido, donde cada intento contra [email protected] viene de una IP distinta (una botnet). El límite por IP no ve nada; el límite por cuenta sí.

Y un matiz que se olvida: solo se cuentan los intentos fallidos. Si cuentas también los correctos, un usuario legítimo que entra y sale varias veces acaba bloqueado. express-rate-limit lo soporta con skipSuccessfulRequests: true.

Cuidado también con el efecto secundario del límite por cuenta: si bloqueas la cuenta durante 15 minutos tras cinco fallos, un atacante puede negar el servicio a un usuario concreto fallando a propósito. Mitigaciones: retraso progresivo en vez de bloqueo duro, ventana corta, y no bloquear si la petición viene de una IP que ya ha entrado con éxito en esa cuenta antes.

Notas sobre estos números, que importan más que los números mismos:

• Los valores son un punto de partida. El procedimiento correcto es medir el percentil 99 del uso legítimo real y poner el límite bastante por encima. Un límite que corta a usuarios reales cuesta más que uno demasiado generoso.
• Empieza en modo observación. express-rate-limit permite contar sin bloquear (skip que solo registra). Dos semanas de datos dicen mucho más que cualquier estimación.
• El nivel se deriva del token, así que el rate limiting específico por rol debe ir después de autenticar. El límite global anónimo, en cambio, va antes: tiene que proteger incluso de quien manda tokens basura.

Cuatro decisiones de diseño detrás de esa respuesta:

Retry-After siempre. Sin ella, el cliente educado no sabe cuánto esperar y el maleducado reintenta de inmediato, empeorando el problema. Admite segundos o una fecha HTTP; los segundos son más fáciles y no dependen del reloj del cliente.

Las cabeceras informativas en todas las respuestas, no solo en el 429. Su valor está en que el cliente pueda frenar antes de chocar: si ve Restantes: 3, espacia sus peticiones. Enviarlas solo al fallar desperdicia el mecanismo.

El prefijo Aroma-, coherente con el contrato (nunca X-, como decidimos en 02-05). Existe un borrador de la IETF que estandariza RateLimit-Limit, RateLimit-Remaining y RateLimit-Reset —y una forma combinada RateLimit: limit=60, remaining=0, reset=37—. Cuando se publique como RFC conviene emitir ambas durante un tiempo y documentar la migración; mientras tanto, el prefijo propio evita colisiones con lo que hagan los intermediarios.

El código limite_peticiones del catálogo, con el mismo formato de error que todo lo demás. Un 429 que devuelve texto plano rompe a los clientes que parsean errores.

Y una advertencia de CORS que se paga cara: la SPA no puede leer ninguna de esas cabeceras desde JavaScript salvo que se declaren en Access-Control-Expose-Headers. Es exactamente el tipo de detalle que hace que un mecanismo bien construido no sirva de nada, y lo resolvemos en 04-05.

Y la fábrica de errores que falta en src/errores/error-api.js (el código limite_peticiones ya estaba en el catálogo desde 02-04; solo añadimos su constructor):

Por qué en la posición 6, y no antes ni después:

• Después de helmet y CORS, para que el 429 lleve las cabeceras de seguridad y, sobre todo, las de CORS: si no, la SPA recibe un error de red opaco en lugar de un 429 legible.
• Antes del parser de JSON. Si el limitador fuera después, tu servidor estaría parseando y validando 100 kB de JSON de peticiones que va a rechazar igualmente. Rechazar barato es media defensa de disponibilidad.
• Antes de las rutas, obviamente, porque protege a todas.
• Después del registro (posición 5, 04-07), para que los 429 queden registrados: si no, el ataque es invisible en los logs justo cuando más falta hace verlo.

Hay una excepción deliberada a "antes del parser": limiteLogin necesita req.body.email para su clave, así que se registra dentro de la ruta, después del parser:

La regla general que resume el orden: el límite anónimo va antes de autenticar; el límite por usuario va después.

El almacén por defecto de express-rate-limit es un Map en el proceso. Con una sola instancia funciona. Con tres, ocurre esto:

El límite efectivo se multiplica por el número de instancias, y además es errático: depende de cómo reparta el balanceador. Peor aún, un despliegue reinicia los procesos y borra todos los contadores, así que un atacante solo tiene que esperar a tu siguiente despliegue.

Qué hacer si Redis cae es una decisión de diseño explícita, no un detalle:

• Fail-open (dejar pasar): la API sigue funcionando sin límites. Prioriza disponibilidad; es la opción por defecto de la mayoría y la que elige Tienda Aroma para el límite general.
• Fail-closed (rechazar): más seguro pero convierte una caída de Redis en una caída total.

Un compromiso razonable: fail-open en el límite general, fail-closed en el login, donde el riesgo de fuerza bruta pesa más que la disponibilidad. Y en ambos casos, una alerta: quedarte sin rate limiting y no enterarte es peor que cualquiera de las dos opciones.

El rate limiting no llega a todo. El cuadro completo:

Timeouts del servidor. Node acepta conexiones que no envían nada, y un ataque Slowloris las usa para agotar el pool:

El keepAliveTimeout es una fuente clásica de 502 aleatorios: si tu servidor cierra la conexión reutilizada antes que el balanceador, el balanceador envía una petición por una conexión que se está cerrando. La regla es que el de Node sea mayor que el del proxy.

Coste por consulta. No todas las peticiones cuestan lo mismo, y el cubo de fichas del apartado 4 ya admite un coste:

Es más justo que contar peticiones y es lo que hacen las APIs maduras (GitHub lo llama «puntos»). Requiere documentarlo bien, porque un límite en unidades abstractas es más difícil de entender.

Circuit breaker. Si la pasarela de pago está caída, seguir llamándola con timeout de 30 segundos consume tus procesos y retrasa la recuperación del otro. El patrón tiene tres estados: cerrado (todo pasa), abierto (tras N fallos, se rechaza de inmediato sin llamar) y semiabierto (pasado un tiempo se deja pasar una petición de prueba). Es lo que convierte «el pago está caído» en un 503 rápido en lugar de en una caída general.

Backpressure. Cuando el trabajo entrante supera al que puedes procesar, la respuesta correcta es rechazar (503), no encolar indefinidamente. Una cola sin tope solo cambia una caída rápida por una lenta y con toda la memoria consumida.

429 y 503 se confunden y no son lo mismo:

Nota el trazaId: es un 5xx, así que el contrato de 03-07 lo exige. En el 429, que es 4xx, no aparece.

Cuándo se usa 503 en Tienda Aroma: mantenimiento programado, base de datos no disponible, circuit breaker abierto hacia la pasarela de pago, o sobrecarga detectada por backpressure. Y siempre con Retry-After, aunque sea una estimación: sin ella, todos los clientes reintentan a la vez y el efecto es el rebaño atronador que impide que el servicio se recupere.

Del otro lado del contrato, esto es lo que debe hacer quien consume:

Por qué el jitter no es opcional. Si mil clientes reciben un 503 en el mismo segundo y todos esperan exactamente 1, 2, 4 y 8 segundos, los mil vuelven a la vez cuatro veces seguidas. El servicio, que estaba recuperándose, se cae de nuevo con cada oleada. La aleatoriedad reparte la vuelta en el tiempo y es la diferencia entre recuperarse en un minuto o no recuperarse. Es un fallo de sistemas distribuidos tan común que tiene nombre propio: rebaño atronador.

Y las tres reglas complementarias:

• Frenar antes de chocar: si Aroma-RateLimit-Restantes baja de un umbral, espaciar las peticiones en lugar de esperar al 429.
• No reintentar los 4xx de cliente. Un 400 o un 422 van a fallar igual la segunda vez. Solo 429 y 5xx.
• Cachear. El mejor reintento es la petición que no se hace: si el catálogo no ha cambiado, no vuelvas a pedirlo. Ese es exactamente el tema de 04-06.

Un límite no documentado es un fallo intermitente desde el punto de vista del consumidor. La documentación debe responder a cinco preguntas, y conviene que estén en una sola página:

1. Cuáles son los límites, por nivel y por endpoint, en una tabla como la del apartado 8.
2. Cómo saber cuánto queda: las cabeceras Aroma-RateLimit-*, con un ejemplo real.
3. Qué pasa al superarlos: el 429 completo, con su cuerpo y su Retry-After.
4. Qué debe hacer el cliente: el patrón de backoff, con código copiable como el del apartado 14.
5. Cómo pedir más: a quién escribir, con qué justificación y en qué plazo.

En openapi.yaml se declara la respuesta 429 en las operaciones afectadas, con sus cabeceras:

El middleware de Express funciona, pero tiene una limitación estructural: para rechazar la petición, ya la has recibido. Tu servidor ha aceptado la conexión TCP, ha negociado TLS y ha ejecutado middleware. Bajo un ataque de verdad, eso ya es demasiado trabajo.

Por eso, en producción, el rate limiting suele vivir en capas:

Las capas se complementan, no se sustituyen. La CDN frena el DDoS que tu proceso nunca aguantaría; solo la aplicación sabe que un socio puede hacer 1.000 por minuto y un cliente 300. Mantener el límite en la aplicación tiene además una ventaja práctica: es la defensa que sigue existiendo si alguien despliega la API sin la CDN delante, o si un atacante encuentra la IP de origen y la llama directamente. Los gateways y sus portales los veremos en 05-06.

Tres cosas que enseña esta prueba:

• El skip en entorno de pruebas es necesario pero peligroso. Necesario porque, sin él, la suite de 03-08 empezaría a fallar de forma aleatoria en cuanto hiciera más de 60 peticiones. Peligroso porque significa que los limitadores reales no se prueban: por eso montamos una app mínima con el mismo handler.
• Se prueba el contrato, no la implementación: código, formato del cuerpo, cabeceras presentes y cabeceras ausentes (X-RateLimit-* no debe aparecer).
• La tercera prueba está deliberadamente floja y su comentario lo explica: sin trust proxy configurado, Supertest siempre parece venir de 127.0.0.1. Probar la separación por IP requiere configurar trust proxy en la app de prueba; es un recordatorio de que probar el rate limiting por IP obliga a replicar la topología de red.

Para probar el límite basado en tiempo sin esperar de verdad, usa el reloj falso de node:test:

Poner el limitador después del parser de JSON. Parseas 100 kB de peticiones que vas a rechazar. Rechaza lo antes posible.

Poner el limitador antes de CORS. El navegador recibe un error de red opaco en lugar de un 429, y el desarrollador de la SPA pierde una tarde.

Usar el almacén en memoria con varias instancias. El límite se multiplica por el número de procesos y se borra en cada despliegue.

Confiar en X-Forwarded-For sin configurar trust proxy correctamente. O limitas a todo el mundo junto, o el atacante cambia de identidad a voluntad.

Contar los logins correctos. Un usuario legítimo que entra y sale acaba bloqueado.

Bloquear cuentas por intentos fallidos sin más. Se convierte en una forma de negar el servicio a un usuario concreto. Retraso progresivo mejor que bloqueo duro.

No enviar Retry-After. El cliente educado no sabe cuánto esperar y el maleducado no espera nada.

Enviar las cabeceras de cupo solo en el 429. Su valor está en que el cliente frene antes de chocar.

Olvidar Access-Control-Expose-Headers. La SPA no puede leer ninguna cabecera propia y todo el mecanismo es invisible para ella (04-05).

Consejo: despliega en modo observación primero. Cuenta sin bloquear durante dos semanas, mira el percentil 99 real y fija el límite bastante por encima.

Consejo: registra los 429 con su clave. Saber que vienen todos de oauth:catabox cambia el diagnóstico por completo (04-07).

Consejo: exime a tu propia monitorización. Nada peor que tu comprobación de salud gastando cupo y disparando alertas falsas.

Para cada situación, elige el algoritmo (ventana fija, deslizante, cubo de fichas) y la clave, y justifícalo:

1. Proteger POST /v1/sesiones de la fuerza bruta.
2. Permitir que la SPA cargue una pantalla que hace 8 peticiones seguidas, sin castigarla.
3. Limitar a CataBox globalmente, aunque actúe en nombre de 500 usuarios distintos.
4. Limitar GET /v1/cafes?q= porque cada búsqueda cuesta 200 ms de CPU.

Escribe una función descargarCatalogo(paginas) que recorra GET /v1/cafes?limite=100&desplazamiento=N durante paginas páginas, respetando el rate limiting: debe frenar preventivamente cuando Aroma-RateLimit-Restantes sea bajo, respetar Retry-After en un 429 y no reintentar más de tres veces por página.

Tras desplegar el rate limiting, soporte recibe estas quejas en el mismo día. Diagnostica cada una y propón la corrección:

• (a) «Desde la oficina de mi empresa, la web deja de funcionar por las mañanas. Desde casa va bien.»
• (b) «Mi app móvil recibe 429 al abrir la pantalla de inicio, pero solo la primera vez tras estar un rato cerrada.» (nota: la app hace 8 peticiones al arrancar)
• (c) «Nuestro script de integración recibe 429 aleatoriamente aunque hacemos 50 peticiones por minuto y el límite es 300.»
• (d) «La SPA muestra "error de red" en vez del mensaje de límite.»

Solución 1

Solución 2

Lo esencial: el frenado preventivo hace que el 429 casi nunca ocurra, el Retry-After se respeta cuando ocurre, el jitter evita sincronizarse con otros clientes, hay tope de intentos y se sale del bucle cuando ya se tienen todos los elementos según total.

Solución 3

(a) NAT. Toda la oficina sale por una IP pública. Con 60/min anónimos, veinte empleados navegando la agotan. Correcciones: subir el límite anónimo; autenticar cuanto antes para pasar al límite por usuario (300/min); y, si la SPA carga el catálogo sin sesión, aprovechar la caché HTTP (04-06) para que la mayoría de esas peticiones ni lleguen.

(b) Efecto de borde con ventana fija. La app hace 8 peticiones de golpe. Si el límite se implementó con ventana fija y estricta, una ráfaga tras un periodo de inactividad puede caer justo en el borde. Corrección: cubo de fichas con capacidad ≥ 20 y tasa 5/s, que es justo el caso de uso para el que sirve. Si el problema fuera de escala y no de ráfaga, la solución alternativa es reducir las 8 llamadas a 1 con expandir, como vimos en 04-01.

(c) Almacén en memoria con varias instancias... al revés. Con memoria y N instancias el límite se multiplica, así que 50/min nunca daría 429. Que sí lo dé apunta a otra causa: la clave está mal elegida y agrupa a varios consumidores. Muy probablemente el script no manda Authorization, cae en la rama ip: y comparte IP con otros procesos del mismo cliente. Corrección: autenticar el script (Client Credentials, 04-03) para que su clave sea su client_id. Otra posibilidad: trust proxy mal configurado hace que todos los clientes compartan la IP del balanceador.

(d) Falta Access-Control-Expose-Headers, o el limitador está antes que CORS. Si el 429 se emite sin las cabeceras Access-Control-Allow-Origin, el navegador bloquea la respuesta y JavaScript solo ve un fallo genérico de red. Correcciones: registrar cors antes que limiteGlobal en src/app.js (es la posición 4 frente a la 6) y exponer Retry-After y Aroma-RateLimit-* en Access-Control-Expose-Headers (04-05).

La disponibilidad es la única propiedad de una API que puede destruir cualquiera sin explotar ninguna vulnerabilidad: basta con llamarla mucho. Has visto por qué toda API pública necesita límites —abuso, scraping, clientes con bucles, coste, equidad y protección de la base de datos—, la diferencia entre rate limiting, throttling y cuotas, y los cuatro algoritmos con su compromiso real entre precisión, memoria y tolerancia a ráfagas, con un cubo de fichas implementado y comentado que incluye la recarga perezosa y la limpieza que casi nadie escribe. Sabes contra qué se cuenta y por qué la IP es una clave problemática entre NAT, IPv6 y proxies, con la configuración exacta de trust proxy; tienes los límites por endpoint y por nivel de Tienda Aroma, y la respuesta 429 completa con Retry-After y las cabeceras Aroma-RateLimit-*. En el proyecto está src/middleware/limite-peticiones.js con express-rate-limit, registrado en la posición 6 de src/app.js —después de helmet y CORS, antes del parser de JSON—, con almacén en Redis para varias instancias y una decisión explícita de qué hacer si Redis cae. Y has añadido timeouts, coste por consulta, circuit breaker y el 503 con servicio_no_disponible, además del cliente con backoff exponencial y jitter que evita el rebaño atronador.

Hay un detalle que ha aparecido tres veces y que ya no se puede posponer: la SPA no puede leer ninguna de las cabeceras que acabamos de diseñar. En 04-05, CORS y políticas de seguridad, empezaremos por el porqué: la política del mismo origen del navegador, qué es exactamente un origen y por qué curl y Aroma Móvil no se ven afectados. Veremos peticiones simples frente a preflight con el intercambio OPTIONS completo en crudo, todas las cabeceras del protocolo —incluida Access-Control-Expose-Headers, que es la que resuelve este problema—, la configuración real de Tienda Aroma con lista blanca por entorno, por qué * y Allow-Credentials son incompatibles, la tabla de errores de consola con su causa y su solución, el clásico preflight que devuelve 401 porque la autenticación se ejecutó antes que CORS, y por qué usamos Authorization: Bearer en vez de cookies —lo que nos hace inmunes a CSRF—.