Hi @roel-charita ,
I wanted to add to what Bob said.
I created a presentation and demo around eventual consistency, explaining how you can deal with the fact that asynchronous communication is involved, and you can’t get an immediate response.
You can find the presentation on our webinars page, or the recording at NDC Oslo or other events, because they might have better sound. And you see me moving around ![]()
The demo is available here on GitHub. It uses request/response pattern with NServiceBus and stores the conversation identifier from SignalR into the headers of each message using a behavior. That way your message handlers don’t have to be reminded to copy it in. When the website than receives the reply message, it extracts the header from the message and uses it to reply to the correct client. If you have scaled out website (or Azure App Services) that needs some extra care with SignalR, because otherwise you might end up in a scaled out instance that has no idea about the connection to the client. But SignalR is able to deal with that.
And this is just one possible scenario, but I wanted to give you some ideas and options. Hope it helps.