How to maintain SseEmitters list between multiple instances of a microservice?

user_9184636 0
Viewed 1434

Language: Spring Boot, JS

Overview: I am implementing server sent events functionality in my application which will be deployed in cloud foundry, wherein based on a new message in a queue(which I have subscribed in my micro-service), I will send some update to my client/browser(which is using EventSource). For this, I am maintaining a SseEmitters List(for mainitaining all the active SseEmitter) on my server side. Once I receive a new message from the queue, based on the id(a field in the queue message), I will emit the message to corresponding client.

PROBLEM: How will the above scenario work, when I scale my application by creating multiple instances of it. Since only one instance will receive the new queue message, it may happen that the active SseEmitter is not maintained in that particular instance, how do I solve this?

server-sent-events microservices spring-cloud spring-boot java
1 Answers

To solve this problem, following approaches can be observed.

DNS concept

If you think about it, knowing where your user (SSE Emitter) is, is like knowing where some website is. You can use DNS-look-alike protocol to figure out where your user is. Protocol would be as follows:

  • Whe user lands on any of your instances, associate user with that instance. Association can be done by either using external component, e.g. Redis or a distributed map solution like Hazelcast.
  • Whenever user disconnects from SSE, remove association. Sometimes disconnect is not registered properly with Spring SSEEmiter, so disassociation can be done when sendig message fails.
  • Other parties (microservices) can easily query Redis/Hazelcast to figure on which instance user is.

Message routing concept

If you're using messaging middleware for communication between your microservices, you can use routing feature which AMQP protocol provides. Protocol would be as follows:

  • each SSE instance creates their own queue on boot
  • user lands on any of SSE instances and instance adds exchange-queue binding with routing key = user uid
  • Whenever user disconnects from SSE, remove association. Sometimes disconnect is not registered properly with Spring SSEEmiter, so disassociation can be done when sendig message fails.
  • Other parties (microservices) need to send message to the exchange and define routing key. AMQP broker figures out which queue should receive message based on the routing key.

Bindings are not resource intesive on modern AMQP brokers like RabbitMQ.

Your question is old, and if you didnt figure this out by now, hope this helps.

user_9031990
Related