Here are my retorts on your "Why you should avoid synchronous protocol" section

1) This doesn't hold. Auth token doesn't need to be passed internally at all. It should be validated at the API Gateway/Edge layer, deconstructed to a user token and injected into all RPCs by the service as a common baggage so that no service on the call path has to wire it in manually. For custom service specific logic, it is pretty easy to create a header interceptor/middleware that does this for you.

2) A RPC could be to post an event to a message queue. It has nothing to do with the time/underlying complexity of the operation. You have just shifted the responsibility to the exchange. In fact you could create an RPC to write a "JOB created" event to a stateful store and it would be the exact thing.

3) How can a retry policy create a bottleneck? Are you referring to the retry storm? There are multiple ways to tackle it. In your case, instead of overloading one service, you will overload the entire exchange, potentially disrupting core APIs. In fact, if you restart your instances concurrently, your service might struggle to establish dedicated socket connections with the exchange leading to a massive burst in file descriptors.

4) You can't rely on simple retries to ensure high availability of downstream calls which you don't control. The right way is to use a distributed workflow (e,g Cadence) that processes these jobs in the right manner providing metrics/visibility far greater than what Rabbit would provide. A simple workflow could subscribe to an event/message stream and do its stateful thing along with tons of programmable hooks. Additionally> If you are doing "micro-services right", each service should expose an availability/latency SLA, the breach for which should be acted upon promptly.

5) Again, the "choice" of using buffer could be anything. It could be a local reliable state store like MySQL that would eventually be consumed to apply updates to the "lagging" service. Back pressure semantics should to be built and communicated to the caller. Strict caller quotas may also prevent service abuse.