<p>We have a service with multiple replicas which works with storage without transactions and blocking approaches. So we need somehow to synchronize concurrent requests between multiple instances by some "sharding" key. Right now we host this service in Kubernetes environment as a ReplicaSet.</p>

<p>Don't you know any simple out-of-the-box approaches on how to do this to not implement it from scratch? </p>

<p>Here are several of our ideas on how to do this:</p>

<ol>
<li><p>Deploy the service as a StatefulSet and implement some proxy API which will route traffic to the specific pod in this StatefulSet by sharding key from the HTTP request. In this scenario, all requests which should be synchronized will be handled by one instance and it wouldn't be a problem to handle this case.</p></li>
<li><p>Deploy the service as a StatefulSet and implement some custom logic in the same service to re-route traffic to the specific instance (or process on this exact instance). As I understand it's not possible to have abstract implementation and it would work only in Kubernetes environment. </p></li>
<li><p>Somehow expose each pod IP outside the cluster and implement routing logic on the client-side.</p></li>
<li><p>Just implement synchronization between instances through some third-party service like Redis.</p></li>
</ol>

<p>I would like to try to route traffic to the specific pods. If you know standard approaches how to handle this case I'll be much appreciated.</p>

<p>Thank you a lot in advance!</p>

<p>Another approach would be to put a messaging queue (like Kafka and RabbitMq) in front of your service.
Then your pods will subscribe to the MQ topic/stream. The pod will decide if it should process the message or not.</p>

<p>Also, try looking into service meshes like <a href="https://istio.io/" rel="nofollow noreferrer">Istio</a> or <a href="https://linkerd.io/" rel="nofollow noreferrer">Linkerd</a>.
They might have an OOTB solution for your use-case, although I wasn't able to find one.</p>
