Should the data be validated independently in each microservice?

I have an application in Python and FastAPI with a microservices architecture. So, I perform the data validation with Pydantic. That makes for a lot of pydantic schemas replicated across microservices. But suppose for now I only have two microservices: "backend" and "ds-backend".
"backend" will take the role of gateway and "ds-backend" is a microservice in charge of doing some things with pandas with data that comes from "backend"
So, I have a pydantic schema in "backend" to validate the data that I will serve to the frontend:

class Monitoring(BaseModel):
    type: Optional[EnumType]
    average: int
    max: int
    min: int

Normally, I would have this same scheme in "ds-backend" where I also validate the output data...(then I would validate the data twice, once in "ds-backend" and again in "backend"). Should it be done like this? Or what is the correct approach?
On the one hand, resources are wasted validating data that is already validated (Pydantic also allows you to create schemas without validation, it could be applied). But on the other hand, perhaps in the future "ds-backend" should communicate with other microservices, so it would be necessary to define where it is validated and where it is not.

Usually, you should assume that your microservice is reusable and may be called from many sources. Since different teams with different approaches may develop the callers, it is an excellent decision to perform input and output validations in each of your services, so that they work as independent units.

If you have some domain entities that are shared across multiple services, you may think of:

• Replicate the logic throughout the services. This gives independence to your services and teams (as it is supposed to be), but replicates code across multiple code bases, which increases your maintenance costs and adds risk to your stack since changes to these services may be uncoordinated.

• Creating an independent Python lib that can be used across multiple services. In this lib, you may add the domain validations that can be reused. One downside of this approach is that multiple services will de dependent on this library and changes to it may have a big impact on your stack. Versioning becomes key here.

• Review your design. If multiple microservices are handling the same domain, you may be creating layers in your architecture that do not suit you well and adds unnecessary complexity to your stack. Maybe joining services or rethinking those services' responsibilities. For instance, if the backend service is acting like a gateway, maybe your should code it that way, so it handles aspects such as external security, caching, and so on and then you leave the domain validation to your ds-backend service (maybe changing those names as well).

Hope this helps