Why you should split your Kubernetes-hosted backend app into API and worker mode

Photo by True Agency on Unsplash

In a world of monolithic architecture, it's very common that backend application does not just receive and respond to API request, but also perform scheduling job such as data cleaning, notification sending…

In addition, the same app can also take the job from the queue and execute it. This architecture has tremendous advantage at the beginning as a team can re-use exactly the same code base and infrastructure and can quickly add a new scheduled job.

For example, to have a daily job of clearing expired token at 2am, in Spring Boot you can do this:

This works fine, but not optimal. API and job execution mode are essentially very different:

Enough said, how can we split a Spring boot backend app on Kubernetes into worker mode (for executing job) and API mode? It's very easy indeed by the use of Spring profile. For API mode, it can use normal prod profile and for worker mode, we use both prod and worker profile.

Then we only enable Spring's scheduled mode in worker profile.

Then we do not open the worker deployment with a service so no user can access it with API anyway.

In short, this article analyses and demonstrates why we should split your monolith backend into two modes: API and worker mode.

From my own experience, after the change our API latency is much more stable (as it's not affected by scheduling job) and we can reduce the number of Kubernetes node. We can also effectively scale the number of worker node separately if there are too many jobs in the queue.

How do you think? Feel free to give your feedback and comments here.

Product engineer / novice writer (alexthered.me)

Product engineer / novice writer (alexthered.me)