I wouldn't do it. You should split your services out of necessity, not as a design pattern. Service meshes are also quite immature at the moment and basically guaranteed to give you lots of pain. Inter-service communication adds a ton of complexity and isn't a totally solved problem. The biggest issue is distributed transactions.
Say you have a service that updates two others within the same call. A write "fan out". What happens if one of the writes succeeds and the other fails? Since they don't share the same transaction boundary you need to implement rollbacks yourself. One for every single call you fan-out to. For writes to two services you need to write two rollback mechanisms to handle cases where either call fails.
But it gets even worse. What if the service doing the fan-out dies when its only made one of the two calls, and that first call succeeds? Well now you have no way to rollback, so the next step is to persist "fanout status" to durable storage as each call succeeds.
But it gets worse still... What if you get a service loop? So you write to one service which writes to another and that third service asks your service something all within the same call. WTF is the global view of data consistency when this happens? There isn't one, its undefined behavior.
If you go down this rabbit hole far enough you end up writing your own global database to synchronize everything. The proper way to do "microservices" is to share a datastore so it can handle the transactions and rollback for you. But once you share a datastore, why not just build a monolith that can horizontally scale easily?
I get that some companies are writing services with their own datastores, I've worked on several of these projects myself. They have all been a data consistency nightmare. Write your services like Google does, "monoliths" running hundreds or thousands of instances all connected to the same database that scales in the same way.