Architecture for status updates between several services

Question

I have one frontend that's communicating with a main backend that is in turn using services A & B, using gRPC call-response calls. A and B are each responsible for a hardware component they interact with do to some work. Periodically, both hardware components will change statuses, and these statuses need to be forwarded to the frontend.

To solve this, we have 2 ways in our team we are discussing:

1. Establish a gRPC stream between the main backend and service A, and main backend and service B. Whenever a new status from either is available, each service will send a response over the stream to the backend, which in turn will push it to the frontend. The downside is even stronger coupling between services, we would need to manually implement connection re-establishing cause that is not available out of the box for gRPC streams, and when 3rd party customers also want these status updates, it will further complicate the implementation.
2. Have both service A and B push their status updates on a message queue. The backend will then pick them up and push them to the frontend. This would not introduce additional coupling, messages would not get lost when one of the services goes down, and if more parties would be interested in these status updates, all they would need is subscribe to the relevant topic.

I have a clear preference in number 2, but it seems very hard to convince colleagues of this approach. Maybe I am missing something, so for the sake of objectivity, I wonder what your thoughts are on either approach.

Answer 1

approach #2 seems to be the more reasonable. It would introduce less coupling between the services and increase the overall reliability. Semi-realtime updates can be achieved using a fast streaming service, like Kafka for example. I would use it instead of RabbitMQ as the latter has normally lower throughput due to extra processing in its routing system.