DLQ y procesamiento de mensajes venenosos

La Cola de Carta Muerta (DLQ) es una cola/topic aislada para los mensajes que un consumidor de tiempo completo no ha podido procesar después de un número determinado de intentos o por razones técnicas/empresariales explícitas (esquema no válido, tiempo de espera, conflicto de versiones, etc.). Mensaje venenoso (poison message): un registro que se vuelve a procesar con un error constante y amenaza la estabilidad de la paipline.

El objetivo del DLQ es mantener el SLO, localizar el fallo, evitar que el flujo principal se bloquee y garantizar las capacidades de análisis y re-reproducción segura (redrive).

1) De dónde vienen los mensajes venenosos

Esquemas/contratos: cambios incompatibles, campos obligatorios que faltan, tipos incorrectos.
Validaciones de negocios: duplicados, invariantes interrumpidos, eventos caducados.
Orden y causalidad: llegó «Update» a «Create», correlaciones omitidas, out-of-order.
Idempotencia: el tratamiento repetido produce efectos secundarios.
Dependencias externas: límites/tiempos limitados, inaccesibilidad de la API.
Datos: corrupción de carga útil, codificación incorrecta, exceso de tamaño.

2) Criterios de envío a DLQ

• Se ha superado el tratamiento maxAttempts en el consumer/worker.
• Error clasificado como defectuoso (no retriable): esquema no válido, sin recurso crítico, prohibición empresarial.
• Los mensajes deadline (TTL/expiration) han caducado.
• La política de circuit breaker o control de admision para esta clave/tenant funcionó.
• Solución explícita del operador (manual «eject» del flujo principal).

3) Topologías y patrones DLQ

Per-queue DLQ: cada cola/topic tiene su DLQ. Simple y transparente.
Central DLQ (parking lot): «parking» común para casos complejos, conveniente para herramientas de análisis unificadas.
DLT (Dead Letter Topic): para buses orientados a registros (event log) es un topic separado con metadatos de causa de fallo.
Quarantine: amortiguador de cuarentena con acceso rígido y saneamiento PII para análisis manual.
Shadow-stream: duplicar mensajes problemáticos en una «sombra» para experimentos de fix seguros.

4) Metadatos que están obligados a acompañar a DLQ

• Causa de error: código/clase de error, stack/trace id.
• Contexto de retrés: 'attempt',' maxAttempts', 'first _ seen _ ts',' last _ attempt _ ts'.
• Correlación: 'trace _ id', 'span _ id', 'tenant _ id', 'entity _ id', clave de lote.
• Original offset/partition/sequence (para los neumáticos de la guarida) o message-id.
• Contrato/esquema/versión de carga útil.
• Idempotency-key/Request-id (si lo hay).
• Fuente de enrutamiento: nombre de cola/topic, grupo de consumer.

5) Políticas de retrés hasta DLQ

• Los retiros cortos del consumer son: 'maxAttempts' 2-5, exponential backoff + jitter, caps on concurrency.
• Backpressure cooperativo: reducir la competencia con el aumento de los errores.
• Clasificación de errores: retryable ('5xx', timaut) vs no retryable (validación, schema mismatch).
• Colas pendientes (delay queue): 5s → 30s → 2m para fallos temporales.
• Aislamiento por llave: si «hace ruido» una clave específica, no bloquee todo el lote.

6) Redrave seguro (reenvío desde DLQ)

Redrive es la devolución controlada de mensajes de DLQ al procesamiento.

1. Verificación de fix: redrave sólo después de corregir el código/configuración/esquema o después de restaurar las dependencias externas.

2. Idempotencia: los manejadores deben ser resistentes a la repetición (upsert, operaciones de efecto tolerante).

3. Deduplicación: por 'idempotency _ key '/' message _ id '/' business _ key'.

4. Dosificación y ventanas: batches por N mensajes, rate-limit por redrive, «ventanas» por tiempo/lotes.

5. Validación local: comprobación rápida del esquema antes del redrive (reject de los primeros casos inválidos).

6. Prioridad: el redrive no debe desplazar el tráfico de ventas (baja prioridad de los workers/pool separado).

7. Observabilidad: métricas y tracks individuales para redrive; informe de resultados (éxito/repetición de DLQ/pérdida).

7) Semántica de entrega y orden

At-least-once es el modo más frecuente: la idempotencia y la deduplicación son necesarias.
At-most-once - DLQ se puede desactivar; riesgo de pérdida. Utilice sólo para las pérdidas permitidas.
Exactly-once (eficiente): logrado por las transacciones y el dedup en el almacenamiento de información empresarial; caro y específico.
Orden: DLQ normalmente rompe el orden para una clave/lote en particular. Si el orden es crítico, redirigir por clave y secuencialmente.

8) Esquemas, contratos y validación

Registro de Schema/contratos: versionamiento claro, evolución con compatibilidad backward/forward.
Validación de entrada: cheque barato a través de JSON Schema/Protobuf/Avro antes de pasos pesados.
Política de incompatibilidad: en un campo «rompedor», inmediatamente en el DLQ con el código 'SCHEMA _ INCOMPATIBLE'.
Redaction PII: en DLQ, almacene sólo lo necesario; enmascarar los campos sensibles.

9) Idempotencia y deduplicación

Idempotency-key: forme en un productor a partir del «sentido empresarial» (tenant + entity + operation + ts-bucket).
Registros de dedoup: almacene las últimas claves 'N' con TTL; recuerde el «efecto» de la operación.
Upsert/merge: evite «insert-only» sin restricciones.
Efectos de lado: para llamadas externas: registre y compruebe la «repetición» antes de llamar.

10) Observabilidad y SLO

• Tasa DLQ (msg/s), proporción de mensajes, media/mediana «edad» en DLQ.
• Éxito del redrive (%), repetición de la proporción DLQ.
• Clasificación de causas: schema, validation, timeout, dependency, unknown.
• p95/p99 latencia de procesamiento de flujo principal vs en redrive.
• Tamaño DLQ, riesgo de desbordamiento.

• Etiquetas obligatorias: 'message _ id', 'entity _ id', 'tenant _ id', 'attempt',' reason ',' redrive _ batch _ id '.
• Seguimiento de «rama DLQ»: desde el origen hasta el éxito repetido.

• Porcentaje de mensajes procesados correctamente ≥ X% en T minutos.
• Tiempo de investigación y corrección para el caso DLQ ≤ Y horas.
• Máxima «edad» del mensaje en DLQ ≤ Z horas (con alerta).

11) Seguridad y cumplimiento

Acceso bajo el principio de los privilegios más pequeños: Redrave - Sólo operadores/playbooks.
Auditoría: quién y cuándo activó el redrive/eliminación/edición de metadatos.
Saneamiento: cuando se transfiera a DLQ central, elimine el exceso de PII/secretos.
Retention: políticas de retención y eliminación individuales para DLQ.

12) Multi-tenencia

Etiquetas 'tenant _ id/plan': distingue entre límites, prioridades de redrive, informes.
DLQ o lotes de pen-tenant: para que el cliente «ruidoso» no anote el DLQ general.
Facturación/cuotas: considere el volumen de DLQ y el costo del redrive en usage.

13) Plantillas de configuración (ejemplo)

yaml consumer:
max_attempts: 4 backoff:
strategy: exponential_full_jitter initial_ms: 200 max_ms: 5000 classify_errors:
retryable:  [TIMEOUT, DEP_UNAVAILABLE, 5xx]
nonretryable:[SCHEMA_INCOMPATIBLE, VALIDATION_FAILED, DUPLICATE]
concurrency_caps:
per_partition: 8 per_tenant: 50

dlq:
type: topic name: myapp. events. dlq metadata:
include: [reason, stack, attempt, first_seen_ts, last_attempt_ts, schema_version,
tenant_id, entity_id, trace_id, source_topic, partition, offset]
retention_hours: 168 pii_redaction: true

redrive:
mode: batch batch_size: 500 rate_limit_per_sec: 50 priority: low validate_schema_before_redrive: true idempotency:
dedup_ttl_hours: 24 ordering:
by_key: true

14) Playbooks operativos (runbooks)

1. Crecimiento anormal de DLQ: habilitar throttling prod consumer, analizar las principales razones, comprobar lanzamientos/circuitos.
2. Schema mismatch: reversión/confirmación del esquema, migración del adaptador, redrive después de la validación.
3. La dependencia externa no está disponible: pausa de retrés, habilita la cola delay, redrive después de la recuperación.
4. DLQ repetidos después del redrive: habilitar el manejador/simulador de «sombra», comprobar la idempotencia, estrechar el batch.
5. Desbordamiento DLQ: evacuación al archivo de almacenamiento, activar el redrive selectivo por claves/razones.

15) Pruebas y caos

Inyección de errores: schema-break, validación, timeouts, 1-on-N errores «pegajosos».
Redrave masivo: verificación de la dosificación y del efecto sobre el prod.
Salida de orden de la secuencia: ensure el procesamiento correcto por claves.
La corrupción de la carga útil: validación y rechazo seguro.
Recuperación de la caída del redrive worker: idempotencia de las operaciones de batch.

16) Errores típicos

La ausencia de metadatos en DLQ → es imposible agrupar las causas y redirigir de forma segura.
El redrive masivo sin límites → la degradación repetida de la producción.
No hay idempotencia/dedoop → tomas y efectos secundarios.
Mezclar PII en DLQ central sin necesidad de saneamiento.
La ausencia de esquemas/contratos → «sorpresas» en la evolución de los mensajes.
El único DLQ compartido sin lotes por tenantes/llaves.
Retrés infinitos en lugar de DLQ temprano para errores no retriables.

17) Recetas rápidas

Flujo de negocios convencional: 3-4 intentos, retroceso exponencial con jitter, clasificación temprana de errores, DLQ con metadatos completos.
Eventos críticos (pago): idempotencia estricta, tiempos cortos, mínimo intento, DLQ rápido y análisis manual.
Redrave masivo después de la fix: batches pequeños (100-500), rate-limit, pool separado de workers, monitoreo de éxito> 95% antes de aumentar la velocidad.
Multi-tenant: límites pluma-tenant en el redrive, informe sobre los principales clientes generadores DLQ.

la Conclusión

El DLQ no es un «basurero», sino un circuito de fiabilidad controlado. Reglas claras de acceso, metadatos ricos, idempotencia y deduplicación, redrive dosificado seguro, disciplina de esquemas y observabilidad convierten los mensajes venenosos de una amenaza para SLO en un proceso de ingeniería administrado, con playbooks comprensibles, costos predecibles y un impacto mínimo en los usuarios.