Scalability: using a pool of servers to receive, process and send message

[gopala000]

I have a scenario where background service need to receive message, process the request and send back message to the requested client. I'd like to use a pool of servers for scalability. What is the architectural guidance to make sure that a message is processed only by one server in the pool?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 1bbb2d1c-4dfe-3faf-d4b0-65ae1146961e
• Version Independent ID: 6b203f18-adfa-3a18-183d-b124325064c3
• Content: Host ASP.NET Core SignalR in background services
• Content Source: aspnetcore/signalr/background-services.md
• Product: aspnet-core
• Technology: aspnetcore-signalr
• GitHub Login: @bradygaster
• Microsoft Alias: bradyg

[bradygaster]

@gopala000 are you also thinking of using the Azure SignalR Service? @chenkennt wrote a great blog post describing some new features like stickyness. see the post here: https://devblogs.microsoft.com/aspnet/whats-new-in-azure-signalr-1-1-0-preview-1/

If that's not what you're after let me know and i'll get more info for you on non-ASRS stickness.

[gopala000]

@bradygaster Thanks for your response. I'm not planning to use Azure SignalR Service. My scenario is

1. Request originate from browser client
2. Proxy translates it to a new signalR request to background service
3. Background service process the request and sends the response to client

The example in the content under heading "React to signalR events with background service" has a "break" statement in while loop. That caused background service to end on single iteration. This seems wrong. My questions are

a. What should be the delay in the continuous while() loop? b. In step #2 of my scenario, I used group as receiver of message with server name and processId in string to avoid more than one server process the request in a server farm. This works fine. Just wanted a validation if there is a better approach.

[udlose]

I'd also like to know the guidance. This has been open for 10 months now. Can we have some guidance please? Would using Redis as a backplane solve this problem?

[bradygaster]

adding @davidfowl here as he and I are discussing a series of updates on SignalR architecture. I think this would be near the top of the list of things we'd want to touch on.

[davidfowl]

I don't understand the request so let me try to get some clarity (sorry for seeing this so late). Is this the architecture we're talking about (each box represents another machine):

[Client] <------> [ Server(s) ] <------> [ Workers with background service(s) ]

OR

[Client] <------> [ Server(s) with background service(s) ]

In short, do you want process messages in process or out of process?

I'll just state some relevant things:

• If you want to send a message to a specific client where the request did not originate, you will need something like redis or another backplane even if you have SignalR.
• If you want to offload work from the webserver to a worker service then you need a way to communicate to the worker service (redis, rabbitmq, service bus, pick a queue). If you want to respond to a client from the worker service then you need signalr + redis or you need to send an HTTP request back to the Server to forward the message to a specific client.

What is the architectural guidance to make sure that a message is processed only by one server in the pool?

I'm not sure I understand the question here. Which message, are you trying to send messages to clients or servers? What are you building?