Capítulo 11 - Alta Disponibilidad y Resiliencia del Sistema

Métrica	Objetivo	Cálculo Anual
Uptime	99.9% (Three Nines)	8.76 horas downtime/año
RTO (Recovery Time Objective)	< 15 minutos	Tiempo máximo de recuperación
RPO (Recovery Point Objective)	< 5 minutos	Pérdida máxima de datos
Latencia API	< 200ms (p95)	95% de requests bajo 200ms
Error Rate	< 0.1%	Máximo 1 error por 1000 requests

99.9% Uptime significa:

8.76 horas de downtime permitido por año
43.8 minutos por mes
10.1 minutos por semana
1.44 minutos por día

11.2.1 Réplicas de Microservicios

Mínimo 2 réplicas en producción (hasta 3 para servicios críticos)
Desplegadas en diferentes nodos (anti-affinity rules en K8s)
Health checks continuos cada 10 segundos
Recreación automática de pods fallidos
Rolling updates sin downtime (20% max surge)

11.2.2 Réplicas de Bases de Datos

PostgreSQL Master-Replica con Failover Automático

graph TB
    %% === PRIMARY DATABASE ===
    subgraph PRIMARY[🟢 Primary Database]
        P[Primary
 Read+Write 
Active Master]
    end

    %% === REPLICA DATABASES ===
    subgraph REPLICAS[🔵 Read Replicas]
        R1[Replica 1
 Read-only
📍 AZ-A]
        R2[Replica 2
 Read-only
📍 AZ-B]
        R3[Replica 3
 Read-only
📍 AZ-C]
    end

    %% === FAILOVER MANAGEMENT ===
    FAILOVER[🔄 Patroni/Stolon
Automatic Failover]

    %% === CONNECTIONS ===
    P -->|Streaming Replication
 Asíncrona | R1
    P -->|Streaming Replication
 Asíncrona | R2
    P -->|Streaming Replication
 Asíncrona | R3
    
    FAILOVER -.-> P
    FAILOVER -.-> R1
    FAILOVER -.-> R2
    FAILOVER -.-> R3

    %% === STYLES ===
    classDef primary fill:#E8F5E9,stroke:#4CAF50,stroke-width:3px,rx:15,ry:15
    classDef replica fill:#E3F2FD,stroke:#1976D2,stroke-width:2px,rx:12,ry:12
    classDef failover fill:#FFF3E0,stroke:#FF9800,stroke-width:2px,rx:10,ry:10
    classDef connection stroke:#1976D2,stroke-width:2px
    classDef failoverConnection stroke:#FF9800,stroke-width:2px,stroke-dasharray:5 5

    class P primary
    class R1,R2,R3 replica
    class FAILOVER failover

    linkStyle 0,1,2 stroke:#1976D2,stroke-width:2px
    linkStyle 3,4,5,6 stroke:#FF9800,stroke-width:2px,stroke-dasharray:5 5

11.2.3 Circuit Breaker Pattern

Estados del Circuit Breaker

stateDiagram-v2
    [*] --> CLOSED
    
    CLOSED --> OPEN : Threshold alcanzado
 ej. 50% errors
    OPEN --> HALF_OPEN : Después de timeout
 ej. 30 segundos
    HALF_OPEN --> CLOSED : Request exitoso
    HALF_OPEN --> OPEN : Request falla
    
    note right of CLOSED
        Estado Normal (CLOSED)
        • Request → Servicio ✓
        • Se monitorean fallos
        • Funcionalidad completa
    end note
    
    note right of OPEN
        Estado Abierto (OPEN)
        • Request → Error inmediato
        • NO se llama al servicio
        • Fail-fast pattern
        • Espera timeout
    end note
    
    note right of HALF_OPEN
        Estado Semi-Abierto
        • Intenta 1 request prueba
        • Si éxito → CLOSED
        • Si falla → OPEN
    end note

Servicio	Threshold	Timeout	Reset Time
MS-Datos-Cliente	50% error en 10 req	5s	30s
MS-Pagos	60% error en 20 req	10s	60s
ACH Network (externo)	40% error en 5 req	15s	120s
MS-Notificaciones	70% error en 50 req	3s	20s

11.2.4 Retry con Exponential Backoff + Jitter

Intento 1: Inmediato
  ├─ Falla → Esperar 1s + random(0-200ms)
  │
Intento 2: Después de ~1s
  ├─ Falla → Esperar 2s + random(0-400ms)
  │
Intento 3: Después de ~2s
  ├─ Falla → Esperar 4s + random(0-800ms)
  │
Intento 4: Después de ~4s
  ├─ Falla → Esperar 8s + random(0-1600ms)
  │
Intento 5: Después de ~8s
  └─ Falla → Error definitivo, ejecutar compensación

Jitter (ruido aleatorio): Previene "thundering herd"
cuando múltiples clientes reintentan simultáneamente

11.2.5 Graceful Degradation

Escenario	Servicio Afectado	Comportamiento Degradado
MS-Históricos caído	Consulta movimientos	Mostrar últimos 5 desde caché + mensaje "Datos de hace 15 min"
ACH Network lento	Transferencias interbancarias	Mostrar "Procesando, recibirás notificación" (asíncrono)
MS-Notificaciones saturado	Envío de emails	Queue notifications, enviar cuando se recupere
Redis caído	Caché de sesiones	Leer directo de PostgreSQL (más lento pero funcional)
Firebase caído	Push notifications	Fallback a SMS o solo email

11.3.1 Estrategia de Backup

Tipo	Frecuencia	Retención	Storage
Full Backup	Semanal (Domingo 2am)	3 meses	S3 Glacier
Incremental	Diario (2am)	30 días	S3 Standard
Transaction Logs (WAL)	Continuo	7 días	S3 Standard
Snapshots	Cada 6 horas	48 horas	EBS Snapshots

11.3.2 Plan de Recuperación ante Desastres

Escenario	RTO	RPO	Procedimiento
1 microservicio caído	<2 min	0	K8s restart automático del pod
1 nodo caído	<5 min	0	K8s reschedula pods en otros nodos
Zona AZ completa caída	<5 min	0	Failover automático a otra AZ (multi-AZ deployment)
Región completa caída	<15 min	<5 min	Failover manual a región secundaria
Corrupción de BD	<30 min	<5 min	PITR restore desde WAL logs
Ransomware	<1 hora	<1 hora	Restore desde backup offline (air-gapped)

11.3.3 Database PITR (Point-in-Time Recovery)

Estrategia PITR PostgreSQL

flowchart TB
    subgraph Strategy["POSTGRESQL PITR STRATEGY"]
        direction TB
        
        subgraph Base["Base Backup (Full)"]
            B1["Domingo 2am"]
            B2["Stored in S3 Glacier"]
            B3["Compressed with pg_dump"]
            B4["Retention: 90 días"]
        end
        
        subgraph WAL["WAL (Write-Ahead Logs)"]
            W1["Continuo"]
            W2["Archived every 16MB
or 5 minutes"]
            W3["Stored in S3 Standard"]
            W4["Retention: 30 días"]
            W5["Enable PITR a
cualquier momento"]
        end
        
        subgraph Recovery["Procedimiento de Recuperación"]
            R1["1. Restaurar Full Backup
más reciente"]
            R2["2. Aplicar WAL logs
hasta punto deseado"]
            R3["3. Tiempo recuperación:
15-30 min"]
            R4["4. Pérdida máxima datos:
5 minutos"]
        end
    end
    
    Base --> WAL
    WAL --> Recovery
    
    style Strategy fill:#E8F5E9,stroke:#4CAF50,stroke-width:3px,rx:15,ry:15
    style Base fill:#E3F2FD,stroke:#2196F3,stroke-width:3px,rx:15,ry:15
    style WAL fill:#FFF9C4,stroke:#FBC02D,stroke-width:3px,rx:15,ry:15
    style Recovery fill:#FFE5E5,stroke:#E74C3C,stroke-width:3px,rx:15,ry:15

11.4.1 Sistema de Alertas Proactivo

Alerta	Umbral	Acción	Canal
CPU > 80%	5 min consecutivos	Escalar pods automáticamente	Slack + Email
Error Rate > 1%	2 minutos	Investigación inmediata	PagerDuty
Latencia > 500ms	p95 por 3 min	Revisar cuellos de botella	Slack
Disco > 85%	Instantáneo	Limpiar logs antiguos	Email
Pod restart loop	3 restarts en 5 min	Alerta crítica	PagerDuty
Backup fallido	Cualquier fallo	Acción inmediata	Email + SMS

11.4.2 Dashboard de Operaciones en Grafana

Estado de salud de todos los microservicios
Métricas de negocio: Transacciones/hora, monto total
Latencias por endpoint: p50, p95, p99
Tasa de errores: Por servicio y global
Uso de recursos: CPU, RAM, Disco por pod
Salud de BD y caché: Conexiones, latencia, hit rate

La resiliencia es la capacidad del sistema para resistir, adaptarse y recuperarse de fallos, disrupciones y cambios en la demanda, manteniendo un nivel aceptable de servicio.

Tres Pilares de Resiliencia

graph TB
    Main["RESILIENCIA DEL SISTEMA"]
    
    subgraph Resistencia["RESISTENCIA"]
        R1["• Circuit Breaker"]
        R2["• Bulkhead"]
        R3["• Retry + Backoff"]
        R4["• Timeouts"]
        R5["• Degradation"]
    end
    
    subgraph Adaptacion["ADAPTACIÓN"]
        A1["• HPA/VPA"]
        A2["• Queue-based Leveling"]
        A3["• Adaptive Rate Limit"]
        A4["• Priority Queues"]
    end
    
    subgraph Recuperacion["RECUPERACIÓN"]
        Re1["• Self-Healing"]
        Re2["• Auto Rollback"]
        Re3["• PITR"]
        Re4["• Chaos Engineering"]
    end
    
    Main --> Resistencia
    Main --> Adaptacion
    Main --> Recuperacion
    
    style Main fill:#E8F5E9,stroke:#4CAF50,stroke-width:3px,rx:15,ry:15
    style Resistencia fill:#E3F2FD,stroke:#2196F3,stroke-width:3px,rx:15,ry:15
    style Adaptacion fill:#FFF9C4,stroke:#FBC02D,stroke-width:3px,rx:15,ry:15
    style Recuperacion fill:#FFE5E5,stroke:#E74C3C,stroke-width:3px,rx:15,ry:15

11.5.1 RESISTENCIA - Tolerancia a Fallos Parciales

A) Bulkhead Pattern - Aislamiento de Recursos

Aislamiento de Recursos por Tipo de Operación

graph TB
    subgraph MSPagos["MS-PAGOS (Ejemplo)"]
        direction TB
        
        subgraph PoolConsultas["Thread Pool CONSULTAS"]
            TC1["• 20 threads"]
            TC2["• Timeout: 5s"]
            TC3["• Queue: 100"]
        end
        
        subgraph PoolTransfer["Thread Pool TRANSFERENCIAS"]
            TT1["• 10 threads"]
            TT2["• Timeout: 30s"]
            TT3["• Queue: 50"]
        end
        
        subgraph ConnRead["Connection Pool READ REPLICA"]
            CR1["50 connections"]
        end
        
        subgraph ConnPrimary["Connection Pool PRIMARY DB"]
            CP1["20 connections"]
        end
        
        subgraph PoolNotif["Thread Pool NOTIFICACIONES"]
            TN1["• 5 threads"]
            TN2["• No crítico"]
            TN3["• Puede fallar sin afectar core"]
        end
        
        PoolConsultas --> ConnRead
        PoolTransfer --> ConnPrimary
    end
    
    style MSPagos fill:#F3E5F5,stroke:#9C27B0,stroke-width:3px,rx:15,ry:15
    style PoolConsultas fill:#E3F2FD,stroke:#2196F3,stroke-width:3px,rx:15,ry:15
    style PoolTransfer fill:#FFE5E5,stroke:#E74C3C,stroke-width:3px,rx:15,ry:15
    style ConnRead fill:#E3F2FD,stroke:#2196F3,stroke-width:2px,rx:10,ry:10
    style ConnPrimary fill:#FFE5E5,stroke:#E74C3C,stroke-width:2px,rx:10,ry:10
    style PoolNotif fill:#FFF9C4,stroke:#FBC02D,stroke-width:3px,rx:15,ry:15

Beneficio: Si notificaciones fallan o se saturan, NO afecta las transferencias. Aislamiento total de recursos críticos vs no-críticos.

11.5.2 ADAPTACIÓN - Escalabilidad Dinámica

A) Queue-Based Load Leveling

Absorción de Picos con Colas

flowchart TD
    Traffic["Tráfico Variable

Peak: 10,000 req/s
Normal: 2,000 req/s"]
    
    Queue["KAFKA QUEUE

Buffer: 1M msgs
TTL: 10 minutes"]
    
    Workers["Workers Pool

Process: 3K req/s
Consistent rate"]
    
    Benefits["Beneficios

• Sistema procesa
a ritmo constante
• Ahorro: 50-60% costos
vs aprovisionar para pico"]
    
    Traffic --> Queue
    Queue -->|Consume at
sustainable rate| Workers
    Workers --> Benefits
    
    style Traffic fill:#FFE5E5,stroke:#E74C3C,stroke-width:3px,rx:15,ry:15
    style Queue fill:#FFF9C4,stroke:#FBC02D,stroke-width:3px,rx:15,ry:15
    style Workers fill:#E8F5E9,stroke:#4CAF50,stroke-width:3px,rx:15,ry:15
    style Benefits fill:#E3F2FD,stroke:#2196F3,stroke-width:3px,rx:15,ry:15

B) Rate Limiting Adaptativo

Carga del Sistema	Rate Limit Ajustado	Acción
Baja (<30%)	150 req/min (↑ 50%)	Permitir más requests
Normal (30-75%)	100 req/min (base)	Rate limit estándar
Alta (75-90%)	75 req/min (↓ 25%)	Reducir carga
Crítica (>90%)	50 req/min (↓ 50%)	Proteger sistema

C) Priority Queues

Prioridad	Tipo de Operación	Workers	SLA
CRITICAL	Transferencias >$10K, Nómina	10	<5s
HIGH	Transferencias normales	5	<30s
NORMAL	Consultas, notificaciones	3	<2min
LOW	Reportes, analytics	1	Best-effort

11.5.3 RECUPERACIÓN - Auto-Healing

A) Self-Healing en Kubernetes

Liveness Probe Falla: K8s mata y recrea el pod automáticamente (<30s)
Readiness Probe Falla: Pod removido del balanceador hasta recuperarse
Node Falla: K8s reschedula todos los pods en otros nodos (<5min)
OOM (Out of Memory): VPA ajusta límites y recrea con más memoria

B) Automated Rollback

Métrica	Threshold	Acción
Error rate	+50% vs baseline	Rollback inmediato (<60s)
Latencia p95	+100ms vs baseline	Rollback inmediato
CPU usage	>90% sostenido	Rollback en 2 min
5xx errors	>10 en 1 minuto	Rollback inmediato

C) Chaos Engineering

Game Days (Mensual): Simular fallo de nodo, inyectar latencia, validar auto-recuperación
Chaos Monkey (Producción): Mata 1 pod aleatorio cada hora (horario no-peak 2am-6am)
Latency Monkey: Inyecta 200-500ms latencia en 5% de requests aleatoriamente
Failure Injection (Staging): Simular caída de Redis, Kafka, ACH network

11.5.4 Métricas de Resiliencia

Métrica	Objetivo	Alertas
MTBF (Mean Time Between Failures)	>720 horas (30 días)	<480 horas
MTTR (Mean Time To Recover)	<15 minutos	>30 minutos
Uptime	>99.9%	<99.5%
Auto-Healing Events	<10/día	>50/día
Rollback Rate	<5% de deploys	>10%
Data Loss	0 bytes	Cualquier pérdida

Resultado Esperado:
Un sistema bancario que nunca falla completamente, se adapta a la demanda automáticamente y se auto-recupera de fallos en segundos, manteniendo 99.9% uptime garantizado.