Hello Tobias tjamma, thanks for this feedback.

Although I agree with you that the design of it can be improved, I made it that intentionally for the simplicity of the article.

I wanted an article that is easy to digest and from that point on people can refactor to whatever taste they like.

In any case, here are my considerations regarding your questions:

1. Why not put the SignalR / Notifications in a seperate micro service?
   This could be indeed the proper way to go, as one is easily identifiable as a service that is concerned about notifications and the other is concerned about accepting commands from clients. Also, depending on the amount of connected clients, it could be scaled separately.
2. Use Integration Events(by EventBus) to send Messages from one (Micro)service to one other.
   Again, for the simplicity of the example, it is intentionally made without a message broker. Can you imagine how long the article would be if I also included a service bus bootstrap?
   But instead, I used the MediatR library, which offers the same conceptual separation of messaging: Commands and Events. Eventually a messaging framework would obviously be the way to go, like MassTransit or NServiceBus as they offer recoverability, reporting and a lots of benefits for a production project.
3. Or from a (Micro)service to the SignalR Hub which wil notify the
   client
   I’m not entirely sure if I’d agree on this option as it would just add another hop into the process. By hooking an event handler into the “notifier” you have the desired state. No need for a middle-man here.