Service tasks within Camunda Cloud require you to set a task type and implement job workers who perform whatever needs to be performed. These workers can control the number of jobs retrieved at once and you will have a number of jobs in your local application that need to be processed.
Now you can write blocking or non-blockin workers which will heavily influence scalability of your worker.
The worst-case in terms of scalability is that you process the jobs sequentially one after the other. While this sounds bad, it is valid for many use cases. Most projects I know do not need any parallel processing in the worker code as they simply do not care whether a job is executed a second earlier or later. Think of a business process that is executed only some hundred times per day and includes mostly human tasks - a sequential worker is totally sufficient (congratulations, this means you can safely skip this section of the blog post).
However, you might need to do better and process jobs in parallel and utilize the full power of your worker's CPUs. In such a case, you should read on and understand the difference between writing blocking and non-blocking code.
The code in this repository was developed while writing this blog post: Writing Good Workers For Camunda Cloud
Now this repository contains
#1: REST Server that responds to REST requests with a delay of 100ms to simulate latency of a REST request
#2: Sample code for blocking and non-blocking workers in different languages:
#3: Log statements from my experiments where you can see how workers behave without running them.
