<p>I am developing a series of microservices using Spring Boot and plan to deploy them on Kubernetes.</p>

<p>Some of the microservices are composed of an API which writes messages to a kafka queue and a listener which listens to the queue and performs the relevant actions (e.g. write to DB etc, construct messsages for onward processing).</p>

<p>These services work fine locally but I am planning to run multiple instances of the microservice on Kubernetes. I'm thinking of the following options:</p>

<ol>
<li><p>Run multiple instances as is (i.e. each microservice serves as an API and a listener).</p></li>
<li><p>Introduce a FRONTEND, BACKEND environment variable. If the FRONTEND variable is true, do not configure the listener process. If the BACKEND variable is true, configure the listener process.
This way I can start scale how may frontend / backend services I need and also have the benefit of shutting down the backend services without losing requests.</p></li>
</ol>

<p>Any pointers, best practice or any other options would be much appreciated.</p>

Swordfish
<p>You can do as you describe, with environment variables, or you may also be interested in building your app with different profiles/bean configuration and make two different images.</p>

<p>In both cases, you should use two different Kubernetes <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/" rel="nofollow noreferrer">Deployments</a> so you can scale and configure them independently.</p>

<p>You may also be interested in a <a href="https://kubernetes.io/blog/2016/01/simple-leader-election-with-kubernetes/" rel="nofollow noreferrer">Leader Election pattern</a> where you want only <strong>one active replica</strong> if it only make sense if one single replica processes the events from a queue. This can also be solved by only using a single replica depending on your <em>availability</em> requirements.</p>
