<p>You are looking for the <a href="https://kubernetes.io/blog/2016/01/simple-leader-election-with-kubernetes/" rel="nofollow noreferrer">leader election</a> pattern. This can be implemented in many different ways. It typically means that an instance <em>take a lock</em> in some form of persistent storage, e.g. a PostgreSQL database, Redis or in etcd itself.</p>
<p>Also see <a href="https://java-design-patterns.com/patterns/leader-election/" rel="nofollow noreferrer">Java Leader Election Pattern</a> and <a href="https://kishorenl-official.medium.com/leader-election-in-distributed-systems-8228bc63f31" rel="nofollow noreferrer">Leader Election in distributed systems</a></p>

CC BY-SA 4.0
2021-09-08T19:05:04.867Z
2021-09-08T19:05:04.867Z
Jonas
<p>I have a java web stateful service which connects to mongodb and currently it is being deployed as a jar directly on the VM. This service has a property in properties file i.e. <code>primary</code>.</p>
<p>If we set <code>primary</code> to true then it is primary instance of the application and on this instance mongodb aggregation will happen.</p>
<p>If we set <code>primary</code> to false then it is secondary instance of the application and on this instance no mongodb aggregation will happen but it will serve all read and write queries.</p>
<p>Now we are migrating towards k8s deployment.</p>
<p>Challenges are :</p>
<p><strong>How do we set the value of primary during the k8s pod deployment having multiple replicas ?</strong></p>
<p><strong>How do we handle the failure of primary instance of application pod ?</strong></p>
<p>I am open for any architectural changes suggestions in order to facilitate better deployment structure.</p>
<p>Thanks in advance.</p>

<kubernetes><java><scalability>
Scaling a stateful service which has primary/secondary architecture by setting a property
SRJ
# Scaling a stateful service which has primary/secondary architecture by setting a property

(Asked by: username_0 on 2021-09-07)

I have a java web stateful service which connects to mongodb and currently it is being deployed as a jar directly on the VM. This service has a property in properties file i.e. `primary`.

If we set `primary` to true then it is primary instance of the application and on this instance mongodb aggregation will happen.

If we set `primary` to false then it is secondary instance of the application and on this instance no mongodb aggregation will happen but it will serve all read and write queries.

Now we are migrating towards k8s deployment.

Challenges are :

**How do we set the value of primary during the k8s pod deployment having multiple replicas ?**

**How do we handle the failure of primary instance of application pod ?**

I am open for any architectural changes suggestions in order to facilitate better deployment structure.

Thanks in advance.

**Tags:** kubernetes, java, scalability


---

## 1 answers

### Answer by username_1 on 2021-09-08. Score: 1

You are looking for the [leader election](https://kubernetes.io/blog/2016/01/simple-leader-election-with-kubernetes/) pattern. This can be implemented in many different ways. It typically means that an instance *take a lock* in some form of persistent storage, e.g. a PostgreSQL database, Redis or in etcd itself.

Also see [Java Leader Election Pattern](https://java-design-patterns.com/patterns/leader-election/) and [Leader Election in distributed systems](https://kishorenl-official.medium.com/leader-election-in-distributed-systems-8228bc63f31)


---

