rabbitmq message session stickiness for microservices

1
votes

I was reading about session stickiness for monolithic applications. Wanted to understand the feasibility for microservices.

Q1. what are the downsides of session stickiness for microservices in particular? The internet doesn't talk much about this! It seems to hit scaling badly as the same instance might be overloaded (depending on the other design factors of the application). Is there any advantage? Please throw some light on this

Given rabbitMQ messaging is used for inter microservice communication, is it possible to have session stickiness for rabbitMQ messages, routed to a work queue. i.e, maybe a header in the message has session=xxx and all the messages with the same session reaching that queue are routed to the same client.

RabbitMQ or AMQP doesnt seem to have a configuration like that.

Possible client side implementation:

  1. Publisher publishes handshake message with routing key handshake and session id payload.
  2. Consumer creates auto_delete queue and a binding with topic, topic.sessionid
  3. Publisher publishes message with routing key, topic.sessionid
  4. cleanup accordingly!

Can someone point out the mistakes here

1
rabbitmqmicroservicesamqp
github.com/BaritoLog/wiki/blob/master/_images/… - ProgramCpp

1 Answers

1
votes

The RabbitMQ team monitors this mailing list and only sometimes answers questions on StackOverflow.

Your approach seems reasonable. Topic exchanges and queues bound to that topic is what I would have suggested. Step 1 of your process does require a single queue to synchronize handshake messages with all of your conusmers, which could become a bottleneck depending on your message rate.

Remember that a message that can't be routed anywhere will be lost, so I would suggest reading about alternate exchanges here - https://www.rabbitmq.com/ae.html