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.
![일상 속 기분 좋음 [Proto disco meme]](http://i.ytimg.com/vi/DwmEIaZ7XGQ/mqdefault.jpg)
Brutal!!! Me encantaria poder aplicar estos conceptos a una arquitectura con sns/sqs. Muchas gracias y a la espera de nuevos videos!!❤
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 👌
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 🙌
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.