Resiliencia y Control de Backpressure en Pipelines Asíncronos

En sistemas que ingieren decenas de miles de eventos concurrentes por segundo, la falla no es una anomalía imprevista; es una condición operativa continua. Sin mecanismos explícitos de control de flujo (backpressure), una lentitud temporal en la base de datos receptora puede desbordar la memoria y provocar caídas en cascada a través de toda la infraestructura.

1. El Desafío: Desajuste de Throughput Productor-Consumidor

Cuando la velocidad de publicación supera la capacidad de procesamiento de los workers, los buffers en memoria crecen linealmente hasta provocar Out-Of-Memory (OOM) kills.

Productor (10k req/s) ──> [ Cola de Eventos ] ──> Worker Pool (2k req/s) ──> [ Bottleneck DB ]

2. Estrategias de Contención Implementadas

A. Idempotencia a Nivel de Consumidor

Cada mensaje incluye un idempotency_key generado criptográficamente. Antes de ejecutar operaciones con efectos secundarios, se valida y bloquea la clave en un almacén de estado distribuido con expiración TTL:

INSERT INTO processed_events (event_id, processed_at)
VALUES ($1, NOW())
ON CONFLICT (event_id) DO NOTHING;

B. Ventanas Deslizantes y Throttling Dinámico

En lugar de rechazar peticiones con errores 500, implementamos un circuito de control adaptativo:

• Circuit Breaker (Estado Semi-Abierto): Cuando la tasa de fallos de downstream supera el 5% en una ventana de 10 segundos, el pipeline conmuta a modo de degradación controlada.
• Backoff Exponencial con Jitter: Evita el efecto de tormenta de reconexiones sincronizadas (thundering herd problem).

3. Conclusión

La robustez de un sistema no se mide por su rendimiento en condiciones de carga ideal, sino por su capacidad de degradarse de manera predecible y auto-recuperarse sin intervención humana manual.