🧪 Problem-Driven Systems Lab

💼 Valor de negocio#

Convierte un reinicio inexplicable cada tantas horas —y una pérdida de datos que nadie sabía que existía— en una decisión explícita y documentada sobre qué se sacrifica cuando el sistema no da abasto.

🎯 Resultado de negocio#

Evita caídas por memoria y pérdidas silenciosas de mensajes, y obliga a decidir explícitamente qué se sacrifica cuando el consumidor no da abasto.

🧾 Qué deja como prueba#

  • Contrasta /produce-unbounded y /produce-bounded con las tres políticas sobre la misma carga.
  • Hace visible queue_depth_peak, oldest_msg_age_ms_peak y queue_bytes_peak: profundidad, latencia real y memoria.
  • Expone messages_dropped_total y dlq_depth para que ninguna pérdida quede sin contar.

👀 Qué mirar al evaluarlo#

  • Si queue_depth_peak en la variante sin límite iguala al total producido: la cola absorbió todo.
  • Si oldest_msg_age_ms_peak es 3 o 4 veces mayor sin límite que con límite, con el mismo throughput.
  • Si cada política acotada paga algo distinto: producer_blocked_ms en block, dropped en drop_oldest, dlq_depth en dead_letter.

ℹ️ Estas tres secciones se mantienen sincronizadas con shared/catalog/cases.json, la misma fuente que alimenta al portal y al catálogo.


Caso 15 · Backpressure en colas de mensajes⬅️ 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 ↗