🎄 Happy Holidays! 🥳
Most of Solace is closed December 24–January 1 so our employees can spend time with their families. We will re-open Thursday, January 2, 2024. Please expect slower response times during this period and open a support ticket for anything needing immediate assistance.
Happy Holidays!
Please note: most of Solace is closed December 25–January 2, and will re-open Tuesday, January 3, 2023.
Stateless Microservices: Implementing Delayed Redelivery and Timers - (Node.js / Typescript)
Hi,
I am working on a new design for our Solace Consumer/Bridge here at CIBC and I stumbled upon a very interesting article by Steve Buchko that I would like to use to inspire my own design.
https://solace.com/blog/stateless-microservices-example-delayed-delivery-queues/
In principle, I would like to implement this Solace consumer using this retry pattern using Node.js / Typescript.
I just started putting some code together based on what I found in the javascript samples and I am close to having something to show.
I know, however, that this strategy may be controversial and probably not the best in our case.
So, I am considering this an "experiment"
I would love to connect with anyone that had some experience in this area and exchange ideas.
Thanks in advance, Pablo.
Comments
-
Hi @pabloelustondo - Indeed it is a nice hack. If you can share a few pointers on your questions/concerns, that would be great.
1 -
Hi Giri and Tamimi,
Thanks for your reply. I am new to Solace, but I used Kafka with Node.js before in my previous company. Our retry pattern did send the message back to the queue/topic as a retry message in case of failure. So, the article rang a bell to me and sounded logical and familiar.
Implementing the retry pattern inside the consumer microservice with promises/timeouts sounds messy and less elegant. I like the increased observability and the making of the consumers stateless and light.
I would use this pattern to implement a bridge, which gets a message from the queue and calls an http service.
Now, talking to another intelligent consultant at Solace, he warned me about some considerations:
- This pattern may put "too much" load on the Solace broker because I considered having various retry queues for different time delays. So, three retry queues and a dead letter queue per original queue. So, the number of queues would be 4 x Original Number. (I think I am fine here as the number of queues we use now is low, less than 10)
- Also, he pointed to , maybeode.js being a less "mature" platform for implementing Solace consumers when compared to Java. (For now, it seems ok to me). He seemed more comfortable with us implementing a retry mechanism inside the java jms consumer.
Let me know what you think about these two concerns.
I will share a simplistic POC generic code soon, I. will love your feedback
0