<p>Hi Microservices Gurus,</p>

<p>I had a question on service to service communication architecture of Microservices.
Istio or any service mesh can make the routing, discovery and resilience of Microservices' communication easy to manage. However, it does not cover important aspects of transactions spanning over more than one Microservice( Kind of distributed transactions) , which is included well in the event based architectures of Microservices.  However, apparently, event driven architecture misses the aspects which service mesh covers well. So , was wondering, which is the better approach or there can be a way to mix both -service mesh with event driven architecture to leverage advantages of both patterns. But if that mix is possible, then would the event driven bus (like Kafka) not interfere with internal working patterns of side car proxies/control plane which Istio uses.</p>

<p>You are mixing up several things.</p>
<ul>
<li>Istio, linkerd etc. addresses some of the fundamental design/architecture issues which come up with cloud native, containerised microservices. e.g. service discovery, circuit breakers etc. Those concerns used to be addressed using libraries which are embedded within application like Spring cloud, hystrix, ribbon etc. Service meshes solve this problem within the paradigm of container world.</li>
</ul>
<p>But Service meshes do not solve any other inter service data exchange problems which are solved using Kafka or any other message broker. Your microservices can be event driven or not - service mesh will not interfere with that.</p>
