Which and what approach for internal microservices communication?

I am really new in microservices architecture. This is a design I would like to follow in my future software applications. I want to design architecture which is easy to expand into microservices. I don't know if the project will grow into an enterprise application or it will die in the near future. There is a lot of anomalies outside which are going to influence the future of your projects like lack of money or lack of customers.

But now back to the issue of post. I come up with the architecture of one service. It is going to follow the Domain-Driven Design and CQRS pattern. I think that you cannot design the whole system at the beginning of implementation and which part of the codebase should be in independent microservices will show themself in practice. I am currently studying the microservices communication approaches.

By pieces of information provides in this article https://blog.logrocket.com/methods-for-microservice-communication/, we can divide internal microservices communication into three most common disciplines and they are HTTP direct communication, MessageBroker, and Event-driven communication.

HTTP direct communication
I think this one is a bad path to go by default. If you are invoking the API method directly from the code of another service, it is a code smell.
Microservices should be independent and if you are pushed to invoke the API method of another service, maybe you have the wrong design.
In my humble opinion, you should not ever have the urge to wait for a response and always be capable of calling another service API asynchronously. If you have to wait for a response probably because of need to receive data, which are part of your current business rule flow, you have a wrong design or maybe you are in wrong microservices.

MessageBroker
With MessageBroker approach comes a really nice solution for coupling services to independent instances. This looks like a great way to go but also looks complicated to implement and I am not sure if it is not overkilling of my needs. The problem is the question by itself. What are my needs? As I mentioned, I do not know where the project will take me in a few months or years.

Event-Driven communication
In this case, we are not sending messages directly into Consumer's queue, but simply raise an event and it depends on the consumer if he will take an action or stay chill. Also a very nice independent solution of internal communication, but again, Implementing this will be complicated and time-consuming.

I would love to hear opinions of the community in the comments section.

Thank you