I have a system design question that I'm looking for some guidance on. I have two different systems that need to have a basic level of communication. This is abstracted via message queues.
For example, System A is responsible for user account registration. A user access System B and enters the user registration flow. After the user submits their details, they are sent to System B's Loading / Waiting screen, and they register a long-polling request with System B awaiting the completion of their account. On the back-end, System B places a message with registration details onto a message queue. System A consumes this message, creates the account, then places a message onto a separate queue indicating that registration is completed. System B consumes this message, and needs to notify the user that the registration is complete. This is where the problem lies. System B is running a cluster of servers, and there is no guarantee that the server which is holding onto the long-polling request is the same server that processes the registration completed message.
This seems like it should be a common problem, but I haven't been able to find much discussion on it. I've explored some options, but they all seem to come with some level of downside.
- When System B consumes the registration completed message, use something like JGroups to broadcast this to all other servers within the cluster
- Each instance dynamically creates its own SQS queue and use the SNS-fan out pattern to deliver the message to all of these queues so all servers receive a copy of the message
- Keep track of which server the request is on and find a way to route the message to the appropriate server (this is especially tricky as there is an edge case where during the routing, the request time outs and another request by the same user is initiated and handled by a different server)
- Just use standard polling to eliminate the aspect of server-state
Any insight or suggestions on this problem are greatly appreciated. Thank you.