6. Resiliencia, performance y escalabilidad

Conclusión. El pico 10x de lecturas no llega al legado: se resuelve desde Redis, con cuotas por partner que impiden que uno consuma la capacidad de todos. Lo que sí llega al legado pasa por adaptadores con límite de concurrencia, circuit breaker y Kafka como amortiguador. Los fallos asíncronos se reintentan con espera creciente y terminan en colas de fallidos con alerta. En el demo, con el pico 10x, el p95 de stock y precio queda en 1,6 ms sin errores y las llamadas al ERP no crecen; con el ERP caído, las lecturas siguen respondiendo (sección 6.8).

6.1 Rate limiting por partner y canal

Dos niveles:

Cuotas iniciales por nivel, en peticiones por segundo:

• La cuota es por partner; si un partner tiene varios canales, comparten cuota salvo que su política diga otra cosa.
• Al exceder: 429 RATE_LIMITED con Retry-After y cabeceras RateLimit-*.
• Las órdenes tienen cuota separada de las lecturas: un pico de consultas no deja a un partner sin poder vender.
• Si el servicio de cuotas falla, se deja pasar (fail open) y queda el tope general del gateway.

Trade-off: dos lugares donde se configuran límites y un servicio de cuotas más que operar. Se eligió así porque KrakenD comunitario no tiene cuotas por partner (sección 3.4). Riesgo de construcción declarado: si el rate limit global de Envoy se complica, el plan B es un filtro de cuota en la plantilla de servicio con el mismo contador en Redis.

6.2 Cache: dónde, qué, TTL e invalidación

No se cachea el estado de órdenes, las reservas ni nada de la ruta de crear orden.

El modelo de lectura no es una cache por vencimiento: es una vista materializada que se actualiza por evento, y la invalidación es el evento mismo. Se descartó la cache con vencimiento delante del legado porque cada vencimiento vuelve a golpearlo, y una avalancha de fallos de cache en plena promo lo tumba igual. Los tópicos de estado de Kafka son compactados (conservan el último valor por llave), así que reconstruir Redis desde cero es releerlos.

Frescura prometida, como objetivo de diseño:

Trade-off: el dato puede estar levemente desactualizado. Se acepta porque se declara (asOf, stale), se mide, y porque la decisión que importa, prometer la unidad, no se toma con este dato sino con la reserva.

6.3 Flujo B: consulta masiva en promo, antes y después

En el AS-IS cada consulta de un canal termina en una consulta en línea al WMS o al ERP. Una promo que multiplica por 10 las consultas multiplica por 10 la carga de sistemas que no escalan, y el checkout propio cae junto con las consultas de los partners.

En el TO-BE hay dos rutas con ritmos distintos: la de escritura va al ritmo de los cambios del legado y la de lectura al ritmo de los canales.

Presupuesto de latencia p95, como objetivo de diseño: borde (Cloudflare y balanceador) 20 ms, gateway 10 ms, malla con dos sidecars 5 ms, servicio 15 ms, Redis 5 ms. Total interno: 55 ms, con margen amplio frente a los 300 ms. Capacidad: con el supuesto S4 de 2.000 consultas por segundo y lotes promedio de 10 SKU, son 20.000 lecturas de llave por segundo, holgado para un Redis con una réplica por zona.

6.4 Protección de los legados (backpressure)

Backpressure es el mecanismo por el que un sistema lento frena a quien le envía trabajo en lugar de ahogarse.

1. Por diseño: los canales no llegan al legado. Solo los adaptadores lo hacen.
2. Bulkhead por sistema (límite de concurrencia por dependencia): máximo inicial de 10 llamadas simultáneas al ERP, 10 al WMS y 20 al OMS, más un límite de llamadas por segundo.
3. Kafka como amortiguador: los comandos hacia el OMS se consumen al ritmo que el OMS aguanta. Un pico de órdenes alarga la cola, no la carga del OMS.
4. Circuit breaker por sistema (corte automático de llamadas a una dependencia que falla): abre con 50% de fallos en una ventana de 20 llamadas y prueba de nuevo a los 30 segundos. Abierto, el adaptador pausa su consumo en vez de quemar reintentos.
5. Timeouts de 2 segundos por llamada al legado. Nunca una espera sin límite.
6. Sondeo adaptativo: si el WMS responde lento, el adaptador alarga su intervalo.

Trade-off: con el legado lento, el dato tarda más en llegar a la capa (crece la frescura) y las órdenes tardan más en registrarse en el OMS. Se prefiere eso a que el legado caiga.

6.5 Reintentos y DLQ

Una DLQ (dead letter queue) es la cola donde quedan los mensajes que fallaron tras agotar los reintentos, para revisarlos o reprocesarlos sin bloquear el flujo.

• Errores no transitorios (esquema inválido, regla de negocio) van directo a DLQ, sin reintentos.
• Los reintentos nunca bloquean la partición: el mensaje fallido sale a su tópico de reintento y el consumidor sigue. En oms-adapter, un mensaje con espera larga no frena a los demás del tópico de reintento (corregido el 15/11/2026). El POST que registra la orden en el OMS no se repite tras un timeout, porque podría duplicar la orden; se reintenta por el tópico de reintento.
• El mensaje de reintento y el de DLQ son el original, salvo los datos sensibles: al pasar a la DLQ se reemplazan por --data_redacted-- y la cabecera andes_payload_redacted lista qué campos se enmascararon (ADR-029). El tópico de reintento conserva el original, porque el reintento lo necesita; el token de pago nunca aparece en logs.
• Cada DLQ tiene alerta y un procedimiento de reproceso con rol ops-admin.
• Tras varios fallos seguidos de un partner, su suscripción se pausa y se le notifica; los eventos quedan guardados para reenvío.

Trade-off: Kafka no trae reintentos ni DLQ nativos (con SNS y SQS, las colas y notificaciones de AWS, sí vienen), así que se construyen con tópicos. Se eligió Kafka porque permite releer el pasado para reconstruir el modelo de lectura y garantiza orden por llave.

6.6 Plan para promos

Antes:

1. Prueba de carga a 10x del tráfico esperado, en un entorno igual al productivo, dos semanas antes.
2. Subir el mínimo de réplicas de inventory-service, pricing-service y gateway por escalado programado. No depender del autoescalado reactivo en el primer minuto.
3. Precalentar el modelo de lectura y verificar la frescura.
4. Revisar cuotas con cada partner; subir de nivel a quien lo necesite.
5. Congelar despliegues desde 24 horas antes.

Durante:

1. Activar el modo promo: microcache de 2 segundos en el gateway.
2. Subir la frecuencia de sondeo del WMS solo para los SKU en promoción.
3. Tablero de promo a la vista: p95, frescura, cuotas agotadas, llamadas al legado, órdenes por estado.
4. Degradaciones preparadas, de menor a mayor: servir dato con stale: true, bajar el tope visible de stock, reducir cuotas de los niveles bajos.

Después: revisión con datos, ajuste de colchones de seguridad y de cuotas.

6.7 Escalabilidad

6.8 Evidencia

El mismo escenario de carga se corre contra los dos lados: el AS-IS (simuladores de ERP y WMS consultados directo, como hoy lo harían los canales) y el TO-BE (por la capa). La escala del demo es 20 consultas por segundo en base y 200 en pico: lo que importa es la proporción 10x. Las cifras son de un solo equipo de desarrollo con Docker Desktop, no de producción: sin red entre zonas, sin cifrado en tránsito, sin Cloudflare ni malla. Lo que se compara es el comportamiento a la misma escala y en el mismo equipo; la latencia de producción tiene su presupuesto en la sección 6.3. El umbral de stale del precio se bajó a 45 s para la prueba de caída (en el diseño es 30 minutos). Archivos crudos en tests/load/results/.

Criterio de éxito en el TO-BE para el pico 10x: p95 menor a 300 ms, errores menores a 0,1% y llamadas al ERP y al WMS que no superan la base más 10%. Los seis escenarios de falla dirigida están en el anexo F.

La misma medición en la nube. El AS-IS se repitió en AWS el 14/11/2026 (17:30 a 17:48 UTC): simuladores del ERP, WMS y OMS en el clúster EKS (us-east-1, dos nodos m7i-flex.xlarge en dos zonas) y el generador de carga k6 dentro del mismo clúster, con los mismos scripts, la misma imagen y las mismas perillas que en el equipo de desarrollo. Sin internet, sin Cloudflare, sin gateway de entrada y sin malla: lo que cambia frente a la corrida local es la red entre nodos y el tope de procesador. Archivos crudos en tests/load/results/as-is-nube/.

El AS-IS da en la nube lo mismo que en el equipo de desarrollo: su límite no es la máquina, es que cada consulta llega en línea al legado. El TO-BE se midió en la nube el 15/11/2026 (16:49 a 17:11 UTC, y el escenario 6 repetido a las 17:40 UTC), con los mismos scripts, la misma imagen de k6 y las mismas perillas, entrando por el gateway de entrada de Istio con HTTPS. Los seis escenarios cumplen. Sus p95 son mayores que en el equipo de desarrollo por el TLS del gateway, el mTLS de la malla y la red entre nodos. La primera corrida del escenario 6 incumplió: a bronze se le aceptaron las 100 lecturas por segundo, sin ningún 429, porque el servicio de cuotas no tenía usuario en Redis; se arregló y se repitió, y el detalle está en el README de la corrida. Archivos crudos en tests/load/results/to-be-nube/.

El flujo de órdenes (flujo A) se verificó de punta a punta el 11/11/2026, con todas las piezas reales detrás del borde y el token de cada partner (make f4-e2e). Son pruebas de comportamiento, que pasan o fallan, y no de carga; no tienen columna AS-IS porque el AS-IS no tiene saga ni compensación que probar (sección 4). Algunos tiempos de reintento se acortaron para que la prueba dure minutos (el reintento hacia el OMS, por ejemplo, de 1 minuto a 3 s); la saga, los vencimientos y la consulta a la pasarela usan los valores del diseño. Límite de la medición del OMS: el simulador no puede reproducir un OMS real y lento que confirme una orden después de que el adaptador ya la buscó. oms-adapter consulta si la orden existe antes de cada intento, pero no envía una llave de idempotencia al OMS; el "0 de más" vale para el simulador y queda por probar contra un OMS real.

La malla se probó en vivo el 14/11/2026 en un clúster local de Kubernetes (kind, Kubernetes in Docker: un clúster que corre en contenedores del equipo), con Istio y sus sidecars, el proveedor de identidad, el gateway y el gateway de entrada (make mesh-kind-test). El clúster se crea para la prueba y se borra al final.

En el AS-IS el escenario 6 no aplica: no hay cuotas por partner y cada canal llega al legado sin límite propio. Archivo crudo: tests/load/results/to-be/escenario-6-cuota-20261114T202635Z.json.