Temporal turns fragile, multi-step business logic into code that survives crashes, restarts, and week-long waits. This walkthrough opens the box: how an append-only event history makes execution durable, the four server services that run the show, how a task threads through them, and the database underneath — then the practical decision most teams get wrong: self-host on Google Cloud, or reach for Temporal Cloud?
A normal program keeps its state in memory. Kill the process and that state is gone — the half-charged order, the "waiting 3 days for the trial to end" timer, all of it. Temporal's whole reason for existing is to make that not happen.
The trick is event sourcing. Your Workflow code doesn't store state in variables that live only in RAM — every state-changing decision it makes (an activity was scheduled, an activity completed, a timer started, a signal arrived) is written as an event to an append-only Event History in a database. If the worker running your code dies, another worker picks up the workflow, replays the history to deterministically rebuild the exact in-memory state, and continues as if nothing happened.
Two rules fall out of this: your Workflow code must be deterministic (replaying the same history must produce the same decisions), and anything non-deterministic or with side effects — an API call, a DB write, reading the clock — must live in an Activity. Activities are recorded by their result, so on replay they are not re-run; the recorded result is handed back.
The "Temporal Server" ships as a single binary, but inside it are four independent services that can be scaled and even deployed separately. Understanding what each one does is the whole game — it tells you where load goes and what to size when you self-host.
One distinction to hold onto: the Worker service below is the server's internal worker (replication, archival, scheduled/system workflows). It is not your application Workers — those are separate processes running your Workflow and Activity code, which connect in from outside.
Follow a single step of a workflow and the architecture clicks into place. The key surprise for newcomers: Temporal never pushes work to your Workers. Workers long-poll a Task Queue and pull tasks when they're ready. That's what lets you scale workers up and down freely, deploy them independently, and survive them all being offline for a while — the tasks just wait.
Temporal is stateless in its services and stateful in its database. The persistence layer is pluggable, with two logical stores:
The default store runs on Cassandra, PostgreSQL, or MySQL. The visibility store can share that same SQL/Cassandra database for basic listing, or point at Elasticsearch / OpenSearch for Advanced Visibility — rich search over custom attributes. Pick your database by scale: SQL (often managed, like Cloud SQL) is simplest; Cassandra is the path for very high write throughput.
The History service partitions all workflows across a fixed number of history shards. Each workflow execution is hashed by its ID to exactly one shard, and each shard is processed by one owner at a time — so the shard count is your ceiling on concurrent throughput. It's set once at cluster creation and cannot be changed afterward. Too few and you cap your scale; too many and you pay coordination overhead on a small cluster.
Here's the part teams get wrong: they self-host by default because it's open source, then discover they've signed up to operate a sharded, database-backed distributed system 24/7. Running Temporal well means owning the database, the shards, upgrades, backups, and on-call. Temporal Cloud takes all of that off your plate for a consumption price (per "Action").
Self-hosting genuinely wins in a few situations — regulated data that must stay in your VPC or region, strict network isolation, a strong platform team that already runs Kubernetes and Cassandra, or very high volume where the all-in cost finally tips in your favor. Use the finder to pressure-test your own case.
If you've decided to self-host, here's the concrete GCP shape. The server services and your Workers run on GKE; the durable state lives in Cloud SQL for PostgreSQL (or self-managed Cassandra for very high scale); and the official temporalio/helm-charts wire it together. Click a step to see what it involves — or run through the whole sequence.
passwordCommand to fetch short-lived Cloud SQL IAM tokens per connection. Keep the frontend on an internal load balancer and secure it with mTLS; don't expose it to the public internet.temporal-sql-tool to create and version both the default and visibility schemas before the services come up.Durable execution comes from an append-only event history that any worker can replay. Four services run it — frontend (gateway), history (the engine, sharded), matching (task queues), and the internal worker — all over a pluggable database whose shard count is fixed for life. And the deploy decision is a real one: reach for Temporal Cloud unless residency, isolation, or scale-plus-a-platform-team push you to self-host on GKE + Cloud SQL.
No spam — just new posts and learning pages when they ship.
Drop your email and I will send new posts and learning pages your way.
Thanks — you are subscribed.
You can close this dialog now.
We will only email you when there is something new. Unsubscribe any time.