Hello! The official documentation describes examples for creating Activities, Workflow, Workers, but there are no examples of an application in which, for example, there is more than one activity. Are there any design guidelines for microservices?
Let me explain. Suppose there is an application of 4 Java microservices that work with temporal:
- Where should the creation of workers that perform workflow / activity tasks take place? Should it be a separate microservice or not?
If not, then it turns out that if the metrics are bad sum(rate(poll_success_sync{}[1m])) / sum(rate(poll_success{}[1m]))
and sum(rate(persistence_requests{operation=“CreateTask”}[1m])) we will have to raise the number of replicas of these microservices to increase the number of workers to reduce the queue.
- In one of the examples on the Internet, I saw that the definition of activity interfaces takes place in a shared library, and then each microservice uses this library and implements its own activity. Is this approach good or bad from Temporal’s point of view? It turns out that we somehow connect microservices through java code / java interfaces, which contradicts the microservice approach
Also I didn’t find any information on performance issues.
- What percentage of the time is spent on flow synchronization to go to the server and back, depending on the number of activities?
tihomir or somebody else, please, help me 
Hello @java_dev
Are there any design guidelines for microservices?
I don’t think we have any. The workflow is responsible for coordinating activities invocations, and activities are mainly responsible for communicating with external services(like, in your case microservices through a rest API I guess).
You mostly will need to provide different activity options for each activity, depending on your needs (taskqueueName, startToCloseTimeout, heartbeat… )
- Where should the creation of workers performing workflow/activity tasks occur? Should it be a separate microservice or not?
I think you have got the point. They might have different needs in terms of scalability. You can always start with the easier approach for you, monitor your metrics and change the way you deploy the workers if needed.
- In one of the examples on the Internet, I saw that the definition of activity interfaces takes place in a shared library, and then each microservice uses this library and implements its own activity. Is this approach good or bad from Temporal’s point of view?
Can you point us to the example?
I think it is a good practice to have separate projects for interface and implementations, but in some cases can be overkilling, it really depends on how you build and distribute your project/s. Think of it as any other project structure. If you really have more than one implementation for each activity/set of activities, having different libraries is not a bad idea.
It turns out that we somehow connect microservices through java code / java interfaces, which contradicts the microservice approach
Can you elaborate on this? Sorry, I am not an expert on this topic.
Antonio
Hi, @antonio.perez
https://techdozo.dev/workflow-orchestration-with-temporal-and-spring-boot/
There are two options for workers in the temporal, if I understand correctly.
The first is in the application code, which registers itself to perform certain tasks.
The second is a worker pod that deploys with the temporal helm chart.
In what cases does an increase in the number of replicas of a worker pod occur (second option)?
Hello @java_dev
workers are services that, as any other service, you can bundle and deploy together with other/s services or deploy isolated. To me, the preferred approach is the second one, since they might have different requirements. in addition, keep in mind that you will have to redeploy your workers (or deploy new ones with the new implementation) with any change made in the workflow code. Please see here de different versioning strategies Workflow Versioning Strategies
The first is in the application code, which registers itself to perform certain tasks.
I don’t understand what this means, sorry. Do you mean, deploying your workers within the microservice and calling through direct java invocations from the activities to the microservice?
Thanks,