🧪 Problem-Driven Systems Lab

🩺 Síntomas#

Lo que se ve desde afuera#

  • Nada. Es el síntoma principal y el problema entero.
  • Un cliente reporta que su pedido «nunca llegó», y en la base efectivamente no está.
  • Un reporte de fin de mes que no cuadra por un porcentaje pequeño y constante.
  • Alguien abre la DLQ por curiosidad y encuentra cuatrocientos mil mensajes.

Lo que se ve en las métricas#

  • Throughput normal. El consumidor procesa a la velocidad de siempre.
  • Latencia normal. Fallar rápido es rápido.
  • Error rate en cero. El error se manejó: se mandó a la DLQ.
  • Y una métrica que casi nunca existe: la profundidad de la DLQ.

Lo que hace difícil verlo#

El consumidor está haciendo exactamente lo que se le pidió. Capturar el error, no morirse, seguir con el siguiente mensaje. Eso es resiliencia de manual — y sin la otra mitad, es pérdida de datos con buenos modales.

La segunda dificultad: la DLQ crece despacio. Un 4% de mensajes venenosos no se nota en un día. Se nota a los seis meses, cuando la cola tiene un volumen que ya nadie quiere revisar a mano, y cuando el mensaje más viejo lleva tanto tiempo ahí que su contexto de negocio ya venció.


Caso 20 · La dead letter queue olvidada⬅️ README del caso · ⚖️ Comparativa de los 7 stacks

🗺️ Contexto · 🩺 Síntomas · 🔍 Diagnóstico · 🧠 Causas raíz · 🛠️ Opciones de solución · ⚖️ Trade-offs · 💼 Valor de negocio · 🚨 Postmortem

Ver esta carpeta en GitHub ↗