Performance & Latency Patterns
Temporal Workflows are durable and reliable, but a default implementation—using regular Activities scheduled through the Temporal server—carries inherent latency. Each regular Activity incurs multiple server round-trips, and each new Workflow begins with a Matching Service routing step. On Temporal Cloud, this baseline can reach 850 ms or more for a typical three-Activity workflow.
This section covers three complementary patterns that each target a different source of latency. They can be applied individually or combined depending on your requirements.
Latency sources in a typical Workflow
| Source | Overhead | Pattern that removes it |
|---|---|---|
| Matching Service (first Workflow Task) | ~30–50 ms | Eager Workflow Start |
| Activity scheduling round-trip | ~50 ms per Activity | Local Activities |
| Client waiting for full workflow | Total duration | Early Return |
Pattern comparison
The numbers below are approximate benchmarks based on a three-Activity transaction workflow running on Temporal Cloud. Actual results vary by region, Activity implementation, and server load.
| Pattern | First Response | Total Latency | SDK Support |
|---|---|---|---|
| Baseline (regular Activities) | ~850 ms | ~850 ms | All |
| Early Return | ~265 ms | ~850 ms | All |
| Local Activities | ~275 ms | ~275 ms | All |
| Early Return + Local Activities | ~160 ms | ~275 ms | All |
| Eager Workflow Start + Local Activities | ~265 ms | ~265 ms | Go, Java, Python |
| Early Return + Local Activities + Eager Start | ~160 ms | ~265 ms | Go, Java, Python |
First Response is the time until the client receives an actionable result. Total Latency is the time until the Workflow fully completes.
Eager Workflow Start is not available in the TypeScript SDK, but the latency gap is small (~30–50 ms per Workflow start). Local Activities and Early Return + Local Activities are fully supported and achieve competitive results: ~275 ms total latency and ~160 ms first-response latency respectively.
Patterns in this section
Local Activities
Run Activity functions in-process inside the Workflow Task, eliminating all server scheduling round-trips. Best for short, idempotent Activities on a latency-sensitive path.
Early Return + Local Activities
Extends Early Return by running Phase 1 Activities as Local Activities. The client receives its response after Phase 1 completes entirely in-process, achieving the lowest possible first-response latency.
Eager Workflow Start
Dispatch the first Workflow Task directly to a co-located Worker, bypassing the Temporal Matching Service. Requires the starter and Worker to share the same process and client connection.
Choosing a pattern
You only care about total workflow latency (not first-response time): use Local Activities. If co-location is feasible, add Eager Workflow Start for the maximum reduction.
You care most about first-response latency: use Early Return + Local Activities. The client gets its response in ~160 ms; background work continues independently.
You are using TypeScript: use Local Activities and Early Return + Local Activities. Eager Workflow Start is not available in the TypeScript SDK.
You want to start simple: begin with Local Activities. It requires minimal structural change and provides the most straightforward per-Activity improvement.
Related sections
- Distributed Transaction Patterns — the Early Return pattern lives there, describing the Update-with-Start mechanism in detail
- Worker Configuration Patterns — tuning Worker concurrency and task queue assignments that affect throughput
- QoS & Throughput Patterns — rate limiting and fairness patterns for high-volume workloads