Where to deploy the worker?

Hey, I’m totally new to Temporal and I’m doing a proof-of-concept to find out if temporal would be a solution for our use case. I followed the example project in the documentation of temporal (the ip-address lookup flow) and got everything running. So far so good.

But then I was thinking…. what would this look like in our use case? Therefore I drew two images. You can find them below. It boils down to this:

  1. We have a couple of services (A,B and C). All have an API.
  2. We have a workflow that requires changes in all these services.
  3. The changes differ per service, but are in-general very small and only happen inside the services themselves.

My questions

What is recommended here? How should I proceed / make this decision?

Solution 1

The services are unaware of temporal, I create an “orchestration” service that takes care of the workflow code, but also of triggering the workflow AND running the worker(s). Advantages here is the fact that all “temporal stuff” stays in one place.

Solution 2

Each service gets it’s own “worker” that is configured to run exactly the tasks that should run on the different services. Advantages here are that I don’t have to extend the service’ APIs and that the logic stays close to the services.

The solutions

Other sources

I’d say you want solution 1. at least to get this off the ground.

why?

easier to develop, deploy and debug.

however, solution 2 might be good depending on what you need. I usually tend to have separate workers inside the orchestrator service on different task queues, if I need to rate-limit a specific operation.

one thing that isn’t clear: when do you start these workflows?

Thanks for your reply, @bnpnt ! Helpfull. In our current use case, the ONLY trigger that kicks of a worklflow is an API call. Around 100 times a day and we are 100% free to choose where this API call should live. I think we’ll go for solution 1 indeed; but we will rename the service to something more generic; f.e. “workflow-service”, instead of “orchestration service”.

yup, seems like 1 is going to be the simples way forward! good luck and welcome to a more reliable world with Temporal (seems cliché but it’s true)

1 is not simpler as it requires maintaining separate service APIs and lacks flow control. We recommend it only if you don’t have control over already existing services.