Lección 54 — Resiliencia

Los fusibles de TicketFlow, probados. Sin solutions.md hasta entregar.

Ejercicio 1 — Los timeouts

1. Inventa el sin-timeout: un cliente HTTP sin timeout contra un endpoint que tarda 60 s (simulado): lanza 20 requests concurrentes y observa el pool del 39 (¿cuántas conexiones esperan? ¿el p95 del RESTO del sistema?). Documenta el colapso en cadena.
2. Los timeouts por operación: tabla de TODAS las llamadas remotas de TicketFlow (pasarela, SMTP, Redis, la BD) con su connect/read/write y el criterio del §1 (p99 ×20, menor que el edge). Pega la tabla.
3. El UNKNOWN dirigido: el timeout del cobro dispara el protocolo del 32 (reconciliación): escribe el test: cobro con read-timeout → saga UNKNOWN → reconciliación → CONFIRMED (el ejercicio 3 de la 32 con el timeout REAL, no simulado).

Ejercicio 2 — Los reintentos

1. Implementa with_retry (§2) con backoff+jitter y aplícalo al GET de disponibilidad de la pasarela y al envío del email (el dedup del 29 ya lo hace idempotente). Tests: el flaky que falla 2 veces y a la tercera pasa → ¿cuántos intentos y qué delays (¿el jitter se nota en los logs?).
2. El 4xx no se reintenta: el test: la declinación de la tarjeta (el 402 del 26) NO dispara retry (el mock cuenta las llamadas: 1, no 3) — y el connect-error SÍ (3). La distinción documentada en el cliente.
3. El thundering herd del reintento: 50 clientes con backoff SIN jitter al volver el servicio: ¿qué pico genera? Repite con jitter: ¿el pico se aplana? (el test del 36 en miniatura o el histograma de los delays).

Ejercicio 3 — El breaker

1. Implementa el CircuitBreaker (§3) con estados CLOSED/OPEN/HALF-OPEN y los tests de los 3 estados: 5 fallos → OPEN; a los 30 s la sonda (half-open) sana → CLOSED; la sonda falla → vuelve OPEN.
2. El beneficio medido: con la pasarela simulada caída, 50 VUs del 36 contra el checkout SIN breaker vs CON breaker: pega los dos números (¿el p95 del browse sobrevive en el segundo? ¿el pool del 39 respira?). El breaker que localiza la caída.
3. El breaker observable: la métrica breaker_state{servicio} (46) con la alerta en OPEN > 2 min. Test: el breaker abre → la métrica lo dice → la alerta page (el ejercicio del 46 aplicado al breaker).

Ejercicio 4 — La degradación

1. El modo degradado del checkout: la pasarela caída → el endpoint devuelve 503+Retry-After (26) y la saga retiene el asiento (el 32: "te avisamos") — el test completo: caída → 503 → vuelve la pasarela → la saga retoma → CONFIRMED. ¿El usuario perdió el asiento? (¿la respuesta es NO y por qué?).
2. El feature degradable: las sugerencias del 52 caídas → el flag al revés (apagar lo bonito): el selector manual sigue. El test del modo degradado: el endpoint de sugerencias 503 → el checkout funciona SIN sugerencias (¿qué prueba el E2E del 35 en este modo?).
3. La jerarquía documentada: la tabla endpoint→degradación→lo que JAMÁS se degrada (la invariante de la 10: el asiento duplicado no es degradación) en docs/reference/degradacion.md (48). Máx 15 líneas: el runbook de la caída.

Ejercicio 5 — El game day de resiliencia

1. El juego 1 (pasarela caída): apaga el sandbox, cronometra: ¿el breaker abre? ¿en cuánto? ¿el checkout degrada? ¿la saga retoma al volver? La cronología minuto a minuto (el formato del 47).
2. El juego 2 (la latencia maligna): el proxy con 5 s de delay en la pasarela: ¿el timeout corta? ¿dónde (¿el edge del 42 antes que el tuyo? — el finding del 42 aplicado)? Ajusta los timeouts si el juego los contradice.
3. El informe del game day: los 2 juegos con cronología, gaps (¿la alerta? ¿el fallback? ¿el runbook?) y las acciones (issue/dueño/fecha). El test de la resiliencia: lo que SOBREVIVIÓ el caos y lo que NO.

Entrega

Pega la tabla de timeouts, los tests del breaker con las métricas, el modo degradado del checkout y el informe del game day. Después: Lección 55 — Escalado.