Event-based microservice architecture: best practice for querying complementary event data

In an event-based microservice architecture what is best practice for querying for additional data needed for a microservice handling an event?

Imagine this microservice constellation:

OrderService - receives orders via REST, writes the order to the order database and issues an OrderCreatedEvent, which includes the order data and a customerId.

CustomerService - REST Api for managing customers by using its own customer database, creates an receives different events which are not relevant for the use case

VoucherService - listens to OrderCreatedEvents to sent vouchers to customers.

Here's the qestion: the VoucherService needs more information on the customer (e.g. the address) as is provided in the OrderCreatedEvent - what's the best way to provide the VoucherService with the customer data?

Possible Solutions:

The VoucherService could call the API of the CustomerService, but this violates the lose coupling of services.
The VoucherService could query the customer database, but this would lead to even tighter coupling as changes to the customer database now must be compatible to the VoucherService.
The OrderService could eventually be able to fill the necessary customer data to the event, but this only works if the data is available for some reason and additionally this will lead to problems because in an enterprise environment there could be 50+ fields for a customer and the OrderService doesn't know (and shouldn't know) which of them are necessary for its clients.

Any suggestions how to solve this?

Solution

The solution that you stated:
The OrderService could eventually be able to fill the necessary customer data to the event, but this only works if the data is available for some reason and additionally this will lead to problems because in an enterprise environment there could be 50+ fields for a customer and the OrderService doesn't know (and shouldn't know) which of them are necessary for its clients.

I would suggest to keep the OrderService dumb on customer data, but since you need the customer data in the VoucherService, you VoucherService should be interested on the events coming from CustomerService and store the necessary data that are crucial for the service functionality

There are no silver bullets on solving everything perfectly, but keeping stuff async it will be always the best solution, this requires data duplication and more work, but in the end every service is decoupled and will work without problems on their own