Multiple Dedicated Workers Versus One Worker Registered With multiple Workflow Implementations?

Hi Team,

I have a design/pattern question regarding workers.

Here is my scenario. I am going to eventually have 2 temporal workflows (Workflow 1, Workflow 2) within my service (lets call it service A). Workflow 1 is already running in Production which is tied to its own task queue 1 being polled by Worker 1.
There is a class within this service that is going to create instances of both of these workflows (async executions) after consuming an event from a kafka topic.
Now I am in the process of creating Workflow 2 and there are 2 options.
a. Create a separate Worker (Worker 2) tied to task queue 2 which makes it clean in my opinion. So Service A will end up with 2 workers dedicated to their respective task queues and workflows.
b. Workflow 2 tied to task queue 1 and I register Worker 1 with the Workflow 2 interface and its activities. I do not want to do this as I want to keep things separate and clean.

Is there a reason to chose a over b or b over a ?

I am looking at spawning probably less than 10 instances of workflow 1 and 2 put together per second in production.

There is a class within this service that is going to create instances of both of these workflows (async executions) after consuming an event from a kafka topic.

I think should consider externalizing this service as its own deployment so it can be scaled independently from your worker processes.

Without looking at performance/scalability (which you should also consider), for both options a, b, you should have at least two worker processes deployed for HA. Workflow execs with Temporal are not tied to a specific worker and you want to be able for your executions to continue progress if one of the worker pods/containers shut down for whatever reason.

A single worker can handle many workflows of different types, so you could register your second workflow with same worker if you wanted. In this case yes they would be on the same task queue.
The task queue decision imo is more related to your activities. Do workflows a and b both invoke same activities? Do these activities have any rate-limiting requirements for which they need to have their specific activity task queue and activity worker? Do any require host-specific task queue?
Are any of these activities very cpu intensive and others are not?
Giving more info on this could help.

Is there a reason to chose a over b or b over a ?

For workflows imo both options are fine, again think for the use case would be good to look more at your activities requirements.

Hi Tihomir,

Appreciate your response. See my comments below.

I think should consider externalizing this service as its own deployment so it can be scaled independently from your worker processes.

Unfortunately this is not possible now so the worker process is going to reside in this service that hosts the workflow and creation of the workflow instances.

Without looking at performance/scalability (which you should also consider), for both options a, b, you should have at least two worker processes deployed for HA. Workflow execs with Temporal are not tied to a specific worker and you want to be able for your executions to continue progress if one of the worker pods/containers shut down for whatever reason.

I agree on this. However, I do have 4 pods of this service that has the worker so I am good on HA front as. I will have 4 workers.

 A single worker can handle many workflows of different types, so you could register your second workflow with same worker if you wanted. In this case yes they would be on the same task queue.
The task queue decision imo is more related to your activities. Do workflows a and b both invoke same activities? Do these activities have any rate-limiting requirements for which they need to have their specific activity task queue and activity worker? Do any require host-specific task queue?
Are any of these activities very cpu intensive and others are not?
Giving more info on this could help.

Workflows A and B do not invoke same activities. However there is no rate limiting on any of the activities invoked by workflows A and B, none of these activities are CPU intensive, none of these require host-specific task queue. They are all short running activities that either call a RPC end point or do some CRUD in the DB tied to this service.
I was going through some discussions on the forum and I see that it is best to saturate the worker first unless there is a real reason to create a new worker. In my case, given that I do not expect a lot of load (may be 1 instance of workflow A , 1 instance of workflow B per second ) is it warranted to create a separate worker for workflow B? The only reason here to create a new worker is to keep the code clean but I dont feel that is a good enough reason to add a new worker which may lead to other issues tied to CPU etc. Also the max latency for either of these workflow is around 3 seconds.
I am inclining towards option A with just 1 worker handling workflows A, B and their activities.

In the future if there is a problem, then I can always create a dedicated task queue for workflow B, separate worker for Workflow B handling activities on this queue. I do not want to solve for a problem that doesn’t exist now.
I’d really appreciate your thoughts on this?