Hey Vladimir, thanks for your comment.

In order to keep with simplicity and to make the article easy to read, I kept the focus on how to make an asynchronous use case using SignalR, but adding CQRS principles wouldn't be to hard. CQRS stands for command and query segregation, and in this article, the "command" part is implemented, sending events to whoever is interested on. To add a read capability, simply handling the event "OrderPlacedEvent" and storing the data in any storage optimized for querying would do the job.

Regarding web sockets being more scalable, I agree as it only requires one hand-shake with the server. But SignalR doesn't confront web sockets. In fact, SignalR is transport agnostic, meaning that it will use the best transport available (web sockets) and fall back to other transport if the best option is not available.

Check their documentation: https://docs.microsoft.com/en-us/aspnet/core/signalr/introduction?view=aspnetcore-3.1