If you need to perform two operations from different microservices in one transaction, this means that either both succeed or non of them is performed.
If you do not want an event queue at all, this would mean that one of the microservices invokes the other in a synchronous manner. You would then have to foresee an API that enable the implementation of a two-phase commit. However this creates some coupling between the services and might not scale so much due to waiting microservices.
If you’d go for an event queue, your transaction would be performed asynchronously, leaving more flexibility for scaling-up and avoiding the master microservice to wait for the other. You could implement a two phase commit based on the queued events (you need to foresee the events that enable the two phase commits, though).
All this doesn't require event sourcing, although event sourcing would greatly simplify the management of the commit phase of the two-phase commit protocol, especially the rollback in case of an unexpected issue.