While its certainly possible to use in this mode from what I've experienced most people who deploy applications at scale use an async message bus/queue rather than a request/response. At that point is there even much of a benefit vs. simply using a synchronous request/response oriented service?
I may be off but asynchronously queuing two messages and implementing a synchronous block in business logic does not sound the same to me as a TCP request response cycle.
Correct but TCP provides a reliable data stream between two hosts, the (particular) messaging protocol over it wasn't part of what I was trying to point out.
This is true but I would think that if you had to pick one then it is much easier to make a message broker do reliable request-reply/pull than service mesh do reliable events/push.
"A protocol is the rules and expectations of participants in a system, and how they are beholden to each other. A protocol defines who takes responsibility for failure.
The problem with message brokers, and queues, is that no-one does.
Using a message broker is not the end of the world, nor a sign of poor engineering. Using a message broker is a tradeoff. Use them freely knowing they work well on the edges of your system as buffers. Use them wisely knowing that the buck has to stop somewhere else. Use them cheekily to get something working.
I say don’t rely on a message broker, but I can’t point to easy off-the-shelf answers. HTTP and DNS are remarkable protocols, but I still have no good answers for service discovery."
I would not disagree with any of this but I don't know enough about service meshes to know if they mean that you don't need a protocol (meaning the edges still need to deal with failures after the mesh or broker has retried etc).
One thing a broker gives you is that if the problem is that the other service is busy or down then it will eventually get the message. So it avoids one specific kind of failure in the case where eventual consistency is acceptable.
I don't think it is service mesh OR brokers. Both cater to different use cases.