Programming

I don't want to pretend this is some kind of gospel or anything, but the way I see it messaging frameworks are meant to broadcast to listeners — one directional and 1:n. And to use a radio analogy, the radio broadcasts music, but you don't have to update them that you've heard a song. And if you do need to send something back, you pick up the phone and make a (rest) call.

I think if you need bidirectional communication between systems, they are coupled in a way that just makes sense to use rest calls (even those are almost always going to be one client, one service, not each one calling the other, right?). If you've got an architecture idea I'd be happy to entertain it. There are probably whole industries with use cases I've never encountered before. But as far as I can tell, using an event framework was never intended for bidirectional communication.

That being said, I can imagine an application that listens to a sales stream and identifies inventory that needs to be shipped from a warehouse, and then the warehouse broadcasts a stream of shipping data. But even in that case, I feel like the listener that generates loading orders and the broadcaster that updates the states of outbound shipments would be two separate services.