Cómo gestionar Errores en un Sistema de Mensajería
ฝัง
- เผยแพร่เมื่อ 5 ก.พ. 2025
- En el mundo de la Arquitectura de Software y Sistemas Distribuídos, cuando entras dentro del mundo de las colas de mensajería, surge la pregunta de: ¿Cómo puedo gestionar un error al consumir un mensaje?. Hoy vamos a resolver esa duda.
→ Curso RabbitMQ: bit.ly/curso-r...
﹤🍍﹥ Codely
├ 🎥 Suscríbete: th-cam.com/users/c...
├ 🔖 Cursos: bit.ly/cursos-...
└ 👋 Redes sociales:
├ / codelytv
├ / javiercane
├ / rafaoe
├ / codelytv
└ / codelytv
Justo hoy lo acabo de implementar como aquí se explica y fue una barbaridad. Este video como muchos otros de este canal fue de una ayuda increíble.
Gracias por comentar!
Increíble. Yo suelo implementar el Retry Pattern a nivel de aplicación cuando uso RabbitMQ. No tenía idea de que era posible hacerlo totalmente a nivel de infraestructura. Lo podré en práctica.
Brutal!!! Me encantaria poder aplicar estos conceptos a una arquitectura con sns/sqs. Muchas gracias y a la espera de nuevos videos!!❤
Estaría bueno un video para implementar los patrones Outbox/Inbox para resolver tipo de problemas
@CodelyTV podrian compartir la encuesta para los videos de SQS, han pensado en hacer videos de EventBridge?
Sí y sí!! Aquí tienes la encuesta forms.gle/Cpkz7GtsmpfagkwBA 🙌
Tengo un caso implementado donde un evento de una nueva orden de un ecommerce ingresa a una cola para notificar que se ha procesado por el ERP, pero si la misma está en el estado 'window-to-cancel' queda dando vueltas en loop por 15 minutos que es el tiempo en qué esa orden cambia a 'ready-for-handling' que es recién cuando me acepta la notificación el ecommerce. En este caso, podría cambiar el TTL de la retry a 15 minutos por ejemplo para que reintente ese tiempo sacandola de la queue principal por ese tiempo?
Así configuré yo mis eventos. Usando la misma idea. Y el sistema es muy robusto. En los casos más graves se acumulan en la última cola y saltan alarmas. Es arreglar el problema y mandarlas luego a reprocesar. Mano decsanto esta configuración 👌
Hola, pero estarían usando otra cola .retry solo para meter delay? porque nadie consumiria de ahí verdad? Y con rabbit no tienen "delayed messages" como para republicar con delay en caso de error? Creo que hay un pluggin para dar soporte a los delayed messages. Algo que no mencionan que creo es importante es como manejan el orden de procesamiento con los domain events, porque procesar en desorden no es aconsejable (en gral no, cu lo arma como quiere) pero bueno, me surgió esa otra duda viendo el video porque si el delay no esta a nivel app y el mensaje se redirecciona a otra cosa entonces sucesivos mensajes pueden ser procesados y luego aparece ese mensaje de retry que estuvo en otro lado y se terminaria procesando en otro orden. Espero haberme expplicado. Saludos
Para evitar el procesar en desorden y el setup de infraestructura de colas adicionales con headers yo creo una alternativa a evaluar podría ser meter el delay a nivel app. Usando rutinas escritas en una librería propia se podría por un lado abstraer el broker, y por el otro customizar sus apis y sus features, y así concentrar la instrucción de delay a nivel código dentro de la librería en un solo lugar, por ejemplo desde afuera quedaría libreria.send() o libreria.sendOrElseDelay(3000ms), etc.. lo que no quita que internamente los libreria.send() tengan un delay por default, se podrian llevar contadores de retry, de todo ahi dentro de esa libreria.