Event-Driven Core, Request-Response Shell (opens in new tab)

As long as you expect _something_ to happen in reaction to your event, even implicitly, you are always coupled to the service that listens for the event in some way. After all, what do you do if it doesn't happen (in time)? Communicating through the event channel removes the direct runtime coupling between the two bespoke microservices and replaces it with direct coupling to the event channel. The B microservice no longer has to be available at the time of A's request/event, but that's all that you get (and it is only an improvement because the event channel is a much more mature program than our own crappy B microservice). As mentioned in a comment on the blog website, you could also achieve the same kind of indirection through some sort of "asynchronous RPC" like temporal.io, by polling changes in a shared database, etc.