Async request/response vs messaging/event driven in microservices

I’ve been reading a lot on why you should avoid synchronous http requests in microservices communication. For asynchronous communication the suggestions I find are mostly about using a messaging system and apply a pub/sub event driven pattern. I totally understand that synchronous http requests between services can lead to tight coupling and chain of failures, since all necessary services have to be online at the same time.

On the other hand, there are also asynchronous request/response options (such as http callbacks in javascript), which are non blocking. I know js callbacks are still http based and require an eventual response to finish execution, but if it’s asynchronous, it also doesn’t require all services to be online. I never see that option being mentioned, it’s always the same messaging over sync request/response talk.

And when I mention async request/response I’m not suggesting applying that to inter service communication, because direct communication between services makes them dependant and with too much knowledge about each other, sync or async. I’m suggesting using an API gateway or any other central unity (orchestrator) to make those asynchronous requests to the services. Plus, in event based messaging solutions, services have knowledge about other services’ types of events, using orchestration with asynchronous request/response, the services have zero knowledge about each other. Chris Richardson gave a talk in which he described a similar approach as having multiple benefits and very little drawbacks.

Am I missing something here? Can someone talk about async request/response vs messaging systems (I was about to use Kafka and this question emerged)