I've been reading a lot on why one should use messages (w/ event sourcing/CQRS) for microservices communication and I get it. But most of the stuff I read online state that the main reason for using message brokers over direct http REST API communication is the cascade failure effect when a a service is down. Well, that can be solved by making services high available.
For me, the main reason behind using messaging is the fact that if one uses direct http requests then it's a synchronous request, even if using callbacks, the service is still expecting a response and that makes the microservices highly coupled, turning it into basically a distributed monolith (we kind of lose the microservices main benefits, right?).
With an event driven architecture the microservices are decoupled and it's certain that a given request will be executed eventually. But what if I need the requests do be executed synchronously? As far as I understand, a given user can make a request to create a certain entity, and if one the needed services is down, the user will just have to wait for it to go up again to see its entity created. The same goes with high loading scenarios, the "request" won't fail but it can take a long time to processed.
Not to mention read operations, those have to be synchronous.
So, I see two different use cases, using an event driven archicture in microservices is preferred because it enables low coupling between services, but it only fits eventual consistency scenarios. The other use case is when requests do have to be synchronous, would you still suggest using an event driven architecture? Or is it okay to use direct http REST calls between the services? Or microservices shouldnt be used at all when synchronous requests are a requirement?
Update: I changed some terms that were not correct and did not express what I meant