There is no single correct way to do this. I've seen two main approaches, with the second approach having an additional, optional component.
Use a central event bus, like you mentioned. This is easy to implement, and every service knows where to publish messages, and they know where all messages come from. The disadvantage is your micro services architecture now has a single point of failure. If the message bus goes down, the whole ecosystem crumbles in an instant.
Remember that one of the reasons to use micro services is robustness and fault tolerance. An event bus (which is a single point of failure) is not robust, nor is it fault tolerant. Some organizations view the simplicity as more important, so they decide introducing a single point of failure is worth the risk.
Each micro service gets its own message queue. This decentralizes message handling. An outage in one message queue won't cause the whole system to crumble. The downside is now every service needs to know host names and ports for all of the message queues they care about. This increases complexity when adding new services or sunsetting old ones.
- This variation of #2 includes a concept called service discovery. This helps solve problems with deploying new services and shutting down old ones. Each service registers itself when coming online. But now we introduce another single point of failure. If the service discovery agent is down, new services or nodes cannot register themselves. Service discovery solves some problems, but introduces others.
The API gateway does not actually solve issues with messaging architecture. Even if all services make calls through the API gateway, the API gateway needs to decide which message queues to forward calls onto. Plus, an API gateway introduces another single point of failure. Typically an API gateway is used to centralize authentication and rate limiting. Again, it solves some problems, but introduces some more.
Which approach you take is highly dependent on the needs of your system. You must weigh the benefits and drawbacks of each approach and make a judgement for yourself. Remember to keep micro services:
- Independently deployable
- Independently scalable
Do that above all else.
