[geezerjay]

> I recommend looking at a standard messaging protocol like AMQP 1.0, which will allow you to implement the request-response pattern in an efficient manner without message brokers.

Honest question: if the goal is to implement the request/response pattern then why should anyone adopt AMQP instead of plain REST/RPC-over-HTTP?

[lulf]

If you don’t use any other pattern than request-response, I agree there is no point.

If you have a mix of pub-sub, work queues and request-response, it could simplify your dependencies perhaps.

Also AMQP 1.0 has some nice async capabilities and acknowledge modes that I believe goes beyond what http/2 and grpc supports today.

OTOH I don’t have any real world experience operating such a mix of different communication patterns, so it could be the advantage is insignificant.

[geezerjay]

> If you have a mix of pub-sub, work queues and request-response, it could simplify your dependencies perhaps.

That's a good point. Indeed if the project is already rolling with a message bus then it wouldn't make much sense to increase complexity just to use a specific message exchange pattern.

[dagi3d]

eg. That request might take more time than what a http request should. Also, by having workers that consume specific queues/topics, it's easier to scale them with more granularity