Designing workflows and activities properly
In Temporal, a process consists of a workflow, which controls the sequence, and activities, which have an effect – such as calling another system. The workflow code must be deterministic: when it is resumed, it is replayed using the saved history and must arrive at the same decisions.
Random values, the system time, network calls and database access therefore do not belong directly in the workflow, but in activities or in the functions Temporal provides for this purpose. Activities, in turn, should be built so that a retry does not trigger anything twice.
Versioning from the start
Workflows often last days, weeks or months – longer than the time between two releases. If the workflow code is changed while workflows are still running, they must be able to continue according to their previous logic.
Temporal provides mechanisms for this, such as branches in the code for old and new workflows, or workers that run only a specific version. Which approach fits should be settled before the first production workflow – and be part of the tests.
Testing like other software
Workflows and activities can be tested automatically, including with accelerated time for waiting times and deadlines.
In addition, a test that replays saved histories against new code is worthwhile. This reveals before the release whether a change would disrupt running workflows.
Self-hosted or Temporal Cloud?
In both cases, the business logic runs in your workers, i.e. in your environment. The difference is who operates the Temporal server that stores the state of the workflows.
| Criterion | Self-hosted | Temporal Cloud |
|---|---|---|
| Server operation | your team: database, updates, monitoring | Temporal Technologies |
| Location of workflow data | in your environment | with the service, in the chosen region |
| Costs | infrastructure and operating effort | usage-based fees |
| Workers with your business logic | in your environment | in your environment |
Data protection and requirements on data location also count when choosing, because the inputs and results of workflows often contain personal data. Temporal allows this payload data to be encrypted before it is sent, so that the server does not see it in plain text.
What matters in operation
If you operate Temporal yourself, you should settle these points from the start:
- a database for the state of the workflows, such as PostgreSQL, with backups
- separate namespaces per application or environment
- monitoring of queues, errors and stuck workflows
- a tried-and-tested procedure for upgrading the server and libraries
- rules for how long completed workflows are retained
Start small
A step-by-step start with one workflow that delivers noticeable benefit has proven effective:
- 1choose a workflow with noticeable benefit
- 2define the architecture and versioning
- 3implement it and run it alongside the existing approach for a while
- 4set up operations and hand them over to the team