I) I disagree with the "asynchronous first" approach for RPCs across the stack. RPCs should be synchronous by default and async by exception unless there is a really strong reason to do so none of which are highlighted in this article. In fact, there are only two kinds of RPCs if you look at it carefully, Shorter Request/Response and Long Running RPCs. Everything else may be queued. Look at google.longrunning package for example.

II) Second, an event is something which signals that (i) something happened and (ii) carries data. In RPC, the signal is that a request was initiated and the data is the request payload. Your argument in the above comments where you say "For event, use Kafka, for message use Rabbit" lacks basis. As I showed above, you could create an event out of pretty much everything.

III) Conclusion

Almost all of your problems would be solved via a distributed workflow and a reliable mesh that is deployed as an ingress/egress sidecar to all of your application hosts.

Using async RPCs throughout your stack is an operational burden that you most certainly do not want.