I have the following scenario:
You can create an application via application-service. Before the application can be created specific information need to be checked. This information are distributed and only accessible via user-service and product-service.
First idea would be to send a message through all services via service bus and extend it by all necessary data and process the data at the end again in the application service:
->Application-service->User-service->Product-service->Applicaton-service
Second idea would be to store all relevant data redundant in all services. Means the application service has a copy of the user and product data.
Both ideas don´t feel right.
Are there any better approaches?
In service-oriented architecture like you are describing, it is perfectly normal to have data replicated in multiple services, with each extending the core entity specific to that service.
I suggest reconsidering your service boundaries, though. A service is the technical authority for a specific business process. Services are not meant to be aligned with business data.
For example, your Product Service and User Service sound like business data, and the Application-Service sounds too broad, without knowing more information.
Consider an Order-Service that needs information about the products. It may subscribe to ProductCreated events from the Product-Service to populate itself with product information, although likely just a ProductID. The Order-Service does not need to know the product's name, description, price (this may live in the Billing service), etc.
Since a service is the one and only authority for a business process, it therefore should also own the user interface. Composite UI patterns allow rending a single page with components from multiple services. The Application-Service would host the page and the glue that pulls the components together. For more information on that, I found Micro Frontends a good read.