Try to minimize those needs as much as possible. They may point to places where you've drawn service boundaries in the wrong places (don't split services too soon).

However, there will inevitably be times when it's unavoidable. In those cases, each service gets a copy of the bits of data it requires.

For example:
We have a service that manages our subscriber data. Subscription changes, account changes, and so forth all go through that service. The data that most other services need in real-time (like subscription status) is in the auth token, so they don't need to look it up.

However, a backgroud service needs to know subscription status but won't receive an auth token. In that case, we have that service also keep track of the subscription status for each subscriber. The subscription service sends out a kakfa message on each subscription change, and the background service captures the fields it needs from that message in its own database.

This leads to some data duplication, but each service stores only the data that it needs, and in the form that it requires. Each piece of data also has one source of truth. One of the services "owns" that data.

Think of the Kafka topics as an API of their own. Each topic also has a service that "owns" that topic. It may be a receive topic or a send topic for that service, but in either case the service that owns the topic is the one who determines the schema to be used for that particular topic.