<p>Im looking for an inter-service communication solution.</p>

<p>I have 1 service and multiple pods with an incoming gRPC stream. The initial request calls out to an external resource which eventually triggers a request back to this service with a status message. This is on a separate thread and for this example ends up going to Pod B. I would like PodA to respond with this status message. I have tried to demonstraite this with the workflow below.</p>

<p><a href="https://i.stack.imgur.com/ICh2A.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/ICh2A.png" alt="service workflow"></a></p>

<p>The obvious solution here is to add some sort of messaging pattern but I would am looking for help in determining which is the best approach. The example below introduces a service mesh sidecar which would route external requests to a queue which Pod A would then subscribe to. If using AMQP, I would probably look to use <a href="https://www.rabbitmq.com/tutorials/amqp-concepts.html#exchange-direct" rel="nofollow noreferrer">direct exchange</a>.</p>

<p><a href="https://i.stack.imgur.com/v9BzX.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/v9BzX.png" alt="servicemesg-solution"></a></p>

<p>Any further information needed, please let me know.</p>

Christo
<p>Pub-Sub communication between two microservices is a good communication pattern. The book <a href="https://www.manning.com/books/cloud-native-patterns" rel="nofollow noreferrer">Cloud Native Patterns</a> describes exactly this, and the advantage using this pattern over request-response in some cases. See chapter 12.</p>
<blockquote>
<p>12.2 Moving from request/response to event driven</p>
<p>12.3 The event log</p>
<p>12.4 Event sourcing</p>
</blockquote>
<p>This can be implemented with multiple technologies, but using <a href="https://www.confluent.io/blog/building-a-microservices-ecosystem-with-kafka-streams-and-ksql/" rel="nofollow noreferrer">Kafka with microservices</a> is a good fit. Kafka is also a distributed system, designed for cloud, similar to the principles used in Kubernetes.</p>
<p><strong>Your example</strong></p>
<p>To apply this to your example, the <em>queue</em> is the Kafka broker (or RabbitMQ?) and you need a way to post data from the <em>External Resource</em> to the broker. If the <em>External Resource</em> always reply to the pod that the request was from, a <em>sidecar</em> may be a solution. If the &quot;reply address&quot; can be configured, this could be an independent &quot;adapter service&quot; like e.g. <a href="https://docs.confluent.io/current/kafka-rest/index.html" rel="nofollow noreferrer">Kafka REST proxy</a> if Kafka is used as broker. There is probably corresponding proxies for e.g. RabbitMQ.</p>
