Scaling a microservice with frontend and backend instances

10/27/2019

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

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).

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:

  1. Run multiple instances as is (i.e. each microservice serves as an API and a listener).

  2. 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.

Any pointers, best practice or any other options would be much appreciated.

-- Swordfish
kubernetes
microservices
spring-boot

1 Answer

10/27/2019

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.

In both cases, you should use two different Kubernetes Deployments so you can scale and configure them independently.

You may also be interested in a Leader Election pattern where you want only one active replica 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 availability requirements.

-- Jonas
Source: StackOverflow