Multi-tenant service with Temporal

I am looking at using Temporal Service as the core for our Service Orchestration Workflow engine. I would like to expose the Service Orchestration Workflow engine as a service on cloud. Basically each of our service tenant would get set of endpoints using which they can deploy DSL based workflows and basically do operations such as start, cancel, signal etc. Our APIs would take care of the authentication and authorisation in our service. Temporal would not be made directly accessible.
There are couple points that come to my mind before we start digging deeper with our design.

  • From what I understand based on this thread How can I support my use case for multi-tenant system?, currently there is no recommended way to achieve resource level isolation for various tenant. Using namespace I understand is not recommended. Do you see this coming as feature in near future.

  • I am thinking of having a DSL parser and feed the input to a Generic temporal Workflow implementation. I want some guidance on the task queue creation and worker assignment. From the documentation I read, it is fine to have task queues per Business Objects such as Orders or Invoices etc. Can I also have worker per task queue, which would be one worker per running instance. Can this model scale for heavy volumes across tenants.

  • If the above is feasible, is there a querying capability currently available that would allow us to query for Workflow instances and logs based one some GUID which would be tenant specific. Ex. we could append the tenant GUID to temporal generated RUN ID and do a starts with kind of query to fetch all instances.

  • Also, we would want to try running Temporal on SAP HANA DB, do you see any issues with it.

1 Like

First off, super happy that you found Temporal and are considering us! DSL based workflows are a great use case for Temporal when non-technical users need to have some level of control. So everything sounds reasonable.

From what I understand based on this thread How can I support my use case for multi-tenant system?, currently there is no recommended way to achieve resource level isolation for various tenant. Using namespace I understand is not recommended. Do you see this coming as feature in near future.

Temporal is a great solution for multitenant system. At Uber, there are many teams sharing a single Cadence cluster. It’s hard for me to know whether namespaces are a good fit (or if there’s even a solution to your problem) without knowing more. Resource isolation is a very tricky term. While we do plan to add authorization hooks into the system, this is not resource isolation by any means. That being said, we have no immediate plans to improve resource isolation.

I am thinking of having a DSL parser and feed the input to a Generic temporal Workflow implementation. I want some guidance on the task queue creation and worker assignment. From the documentation I read, it is fine to have task queues per Business Objects such as Orders or Invoices etc. Can I also have worker per task queue, which would be one worker per running instance. Can this model scale for heavy volumes across tenants.

This is an absolutely fine way of architecting your application with Temporal. Creating a generic DSL parser workflow is a recommended pattern, @maxim has plans to create a demo of this at some point in the future. Having a task queue and worker per business process is absolutely ok. That being said if you are using Java there may be a slightly higher overhead for each worker you spin up (not Temporal overhead, just Java runtime consumes more memory etc). Having lighter workflow instances is generally the single best thing to ensure scalability of Temporal applications. The more you load into a single workflow instance the less the system can scale.

If the above is feasible, is there a querying capability currently available that would allow us to query for Workflow instances and logs based one some GUID which would be tenant specific. Ex. we could append the tenant GUID to temporal generated RUN ID and do a starts with kind of query to fetch all instances.

There are some ways of achieving this minus the logs part. Temporal does not really provide a comprehensive logging solution and you definitely can’t query logs using visibility API. We do support a visibility API which allows you to query metadata across all instances. By default the fields are defined and limited to what we’ve created, but using enhanced visibility it’s possible to define your own ES indices. This allows you to create custom statuses which can then be set in the workflow and queried using SQL like syntax.

Also, we would want to try running Temporal on SAP HANA DB, do you see any issues with it.

Fundamentally as long as the DB supports single shard multi-row transactions it’s feasible with Temporal. That being said, we have zero experience with this DB and cannot guarantee it will work in any way. I hope this was helpful, we are more than happy to spend time helping you with architecture or other issues you encounter! Also adding Maxim on this topic to make sure I didn’t miss anything!

  • Ry
1 Like