Stateless Microservices: Implementing Delayed Redelivery and Timers - (Node.js / Typescript)

pabloelustondo
pabloelustondo Member Posts: 2 ✭
in General Discussions #1

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

  • giri
    giri Member, Administrator, Employee Posts: 116 admin
    #2

    Hi @pabloelustondo - Indeed it is a nice hack. If you can share a few pointers on your questions/concerns, that would be great.

  • Tamimi
    Tamimi Member, Administrator, Employee Posts: 538 admin
    #3

    I'm sure @stevebu would be happy to chime in if you have any thoughts or discussions around this! :)

  • pabloelustondo
    pabloelustondo Member Posts: 2 ✭
    #4

    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:

    1. 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)
    2. 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

Categories

This Month's Leaders

This Week's Leaders