Simply, when your API publishes event messages, it doesn’t directly send them. Instead, the messages are persisted in a database table. After that, A job publish events to message broker system in predefined time intervals.

Basically The Outbox Pattern provides to publish events reliably. The idea of this approach is to have an “Outbox” table in the microservice’s database.

In this method, Domain Events are not written directly to a event bus. Instead of that, it is written to a table in the “outbox” role of the service that stores the event in its own database.

However, the critical point here is that the transaction performed before the event and the event written to the outbox table are part of the same transaction.

https://itnext.io/the

In example, when a new product is added to the system, the process of adding the product and writing the ProductCreated event to the outbox table is done in the same transaction, ensuring that the event is saved to the database.

The second step is to receive these events written to the outbox table by an independent service and write them to the event bus.

As you can see the above image, Order service perform their use case operations and update their own table and instead of publish an event, it is write another table this event record and this event read from another service and publish and event. 

https://medium.com/design-microservices-architecture-with-patterns/outbox-pattern-for-microservices-architectures-1b8648dfaa27