[lulf]

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. Either “direct” client server as with HTTP , or via an intermediary such as the Apache Qpid Dispatch Router.

With the dispatch router, you can use pattern matching to specify if addresses should be routed to a broker or be routed directly to a particular service.

This is way you can get the semantics that best fits your use case.

[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

[cpitman]

Qpid Dispatch Router/AMQP 1.0 are both very interesting technology. I actually work for Red Hat, and do use Qpid Dispatch a fair bit.

Straight Qpid Dispatch (without waypoint messages to a broker) is basically providing something similar to HTTP, as far as end-to-end acknowledgements and "synchronous" processing (as in both the client and server must be up and stay up for the lifetime of the request). No surprise, this makes it way faster than a traditional broker, while still offering similar delivery guarantees.