Best practices / Recommendations for orchestrating microservices with temporal

Community Support
1

Hello, quick question is there any example showing the best practices for orchestrating microservices with temporal?

For instance:
Is the following configuration ok or maybe is not the right approach?
Is it expected a longer time to respond because activities are not registered in the same worker?

Environment A
workerA.go
workflowA.go (call: activityA and activityB and activityC dinamically)
activityA.go (registered in workerA)

In another path/environment (B):
workerB.go
activityB.go (registered in workerB)

Yet another path/environment ( C):
workerC.go
activityC.go (registered in workerC)

Starter calls workflowA from another place.

1 Like
2

The proposed setup is fully supported and doesn’t impose any performance penalties. Activity invocation is always going through the service and correspondent activity queue. So even if an activity is registered in the same process as the workflow the overhead is the same as if it is registered in a completely different service.

1 Like
3

Thanks Maxim, for your answer.
I’ve created a toy project with the example and it works as expected. However, sometimes I get this kind of warnings as shown below (but any workflow execution is completed with success):

from A worker
2020/10/15 19:41:54 INFO Task processing failed with error Namespace default TaskQueue test WorkerID 7007@aura@ WorkerType ActivityWorker Error unable to find activityType=ActivityB. Supported types: [ActivityA]

from B worker
2020/10/15 19:58:46 INFO Task processing failed with error Namespace default TaskQueue test WorkerID 7094@aura@ WorkerType ActivityWorker Error unable to find activityType=ActivityA. Supported types: [ActivityB]

Is there any way to avoid them? I guess is telling me that in the current worker is not present that activity then temporal finds it in the other worker… something like that…

1 Like
4

Workers receive activity tasks through task queues that reside inside the Temporal service. All workers that listen on a given task queue have to support all activity types dispatched to that queue.

My guess is that you have workers A and B listening on the same task queue and thus receiving each other activities. As worker A doesn’t know about ActivityB all it can do is to reject it. The same happens with worker B and ActivityA.

The solution is to use different task queues for different workers. Make sure to specify the correct task queue name in the ActivityOptions when calling it from a workflow.

4 Likes
5

Maxim, you were right. Thanks for your guidance. Now it is perfect.

1 Like