Estrategias de gestión de errores en un “service bus”

En mi artículo sobre migraciones legacy, describí lo fácil que es equivocarse cuando te alejas de una plataforma legacy. Una de las herramientas que ayuda consistentemente con la escalabilidad es un service bus.

Un data bus es una pieza arquitectónica que te permite:

• Desacoplar las responsabilidades de tus servicios.
• Descargar peticiones sin perder tus datos.
• Evitar cuellos de botella de capacidad.

Hoy en día, los service buses son más relevantes que nunca. Plataformas como RabbitMQ, Apache Kafka, Google Pub/Sub o Azure Service Bus se han convertido en pilares de las modernas arquitecturas cloud-native, event-driven. Ya sean basadas en colas o orientadas a streaming, todas ellas refuerzan la comunicación asíncrona y un modelo pub/sub que permite escalabilidad real.

Por qué importa la gestión de errores

Uno de los aspectos más importantes al implementar una arquitectura event-driven es aprender a aprovechar el service bus para gestionar errores. Piensa, por ejemplo, en los siguientes escenarios:

1. Tu servicio recibe un mensaje e intenta almacenarlo en la base de datos, pero la BD está caída.
2. Tu servicio reenvía datos a una API de terceros — pero falla con un error 500.
3. Tu servicio recibe un mensaje corrupto al que le falta un ID — imposible de procesar.

A primera vista, pueden parecer similares («el mensaje falló»), pero la naturaleza de los errores es fundamentalmente diferente:

• Errores recuperables bajo tu control → ej., tu base de datos temporalmente no disponible.
• Errores recuperables fuera de tu control → ej., un servicio de terceros caído.
• Errores no recuperables → ej., datos malformados que no pueden procesarse en absoluto.

Así, podemos observar que los errores 1 y 2 podrían resolverse (siempre que las dependencias operacionales vuelvan a funcionar correctamente), mientras que el escenario 3 no tiene esperanza. Cada uno de estos problemas requiere una estrategia diferente para gestionar la situación.

Estrategia de reintentos

Cuando el error proviene de infraestructura bajo tu control — por ejemplo, tu propia base de datos — una estrategia de reintentos es la opción más efectiva. Una vez detectada la anomalía, el mensaje vuelve al bus para reprocesarse. Si la BD está saludable la próxima vez, el mensaje tiene éxito y el sistema se cura a sí mismo.

Para evitar bucles infinitos, los reintentos se configuran con:

• Un retraso fijo (ej., un minuto entre intentos), y
• Un número máximo de reintentos.

Una vez alcanzado el límite, el mensaje se envía a una dead letter queue (DLQ). Las DLQs actúan como una red de seguridad: aíslan eventos fallidos, previenen que el sistema se atasque y proporcionan una señal clara para que los operadores intervengan.

El trade-off aquí es velocidad vs. resiliencia. No quieres que los reintentos retrasen demasiado el sistema, pero también necesitas dar a tus propios servicios una oportunidad de recuperarse. En la práctica, encontrar el punto óptimo a menudo requiere observar cargas de trabajo reales en producción y ajustar las políticas de reintentos en consecuencia.

Reintentos con exponential backoff

Cuando la dependencia que falla está fuera de tu control — por ejemplo, una API de pagos de terceros — los reintentos se vuelven más complicados. Reintentar a ciegas con un retraso fijo podría en realidad exacerbar la situación: si cientos de servicios continúan bombardeando la misma API que está fallando, el tiempo de inactividad solo se hace más largo.

Ahí es donde entra el exponential backoff. La idea es simple: esperar más tiempo entre cada reintento, dando al servicio externo algo de aire, de «margen para respirar»:

• primer reintento después de 1 min,
• luego 2,
• luego 4,
• luego 8…

Esta dispersión de intentos reduce la presión sobre el servicio que está fallando y aumenta la posibilidad de recuperación. AWS explica bien este patrón.

La lógica todavía incluye un punto de corte: después de cierto número de reintentos, el mensaje se envía a la DLQ para inspección. Pero comparado con reintentos fijos, el exponential backoff es mucho menos probable que cause problemas de thundering herd, donde cada cliente reintenta a la vez y sobrecarga la dependencia aún más.

Esta estrategia es particularmente valiosa cuando te integras con APIs SaaS, proveedores de pagos o sistemas bancarios — entornos donde el uptime está fuera de tus manos pero tu sistema aún necesita mantenerse resiliente.

Estrategia de dead letter queue

Luego están los errores que nunca tendrán éxito, sin importar cuántas veces los reintentes. Un mensaje corrupto al que le falta su ID, o un evento con un esquema inválido, siempre fallará. Reintentarlos solo desperdicia recursos y añade ruido a tu sistema.

El movimiento correcto es enrutar estos mensajes directamente a la DLQ. Al hacer esto:

• Evitas carga innecesaria del sistema.
• Detectas anomalías más rápido.
• Mantienes tu pipeline fluyendo suavemente.

Una vez en la DLQ, los operadores (o procesos automatizados) pueden inspeccionar los mensajes, identificar causas raíz y decidir si necesitan ser arreglados, reproducidos o simplemente descartados.

En configuraciones modernas, las DLQs también son una valiosa herramienta de observabilidad. Con logging en tiempo real y alertas — ej. vía Better Stack o Datadog — los equipos pueden detectar patrones temprano, como un pico repentino en eventos malformados después de un nuevo release, y actuar antes de que afecten a los clientes en producción.

Conclusión

Los sistemas resilientes tratan los errores de manera diferente dependiendo de su naturaleza. Algunos pueden reintentarse, algunos requieren paciencia, y algunos son callejones sin salida. Independientemente de si usas Kafka, RabbitMQ, Pub/Sub u otro bus, estos tres patrones son universales.

En Orbitant, ponemos estos principios en práctica cuando construimos plataformas para nuestros clientes. Una estrategia de gestión de errores bien diseñada no se enfoca solo de mantener los servicios vivos, sino que protege la integridad de los datos, construye confianza y permite escalabilidad real del negocio.