openskills.info
Temporal Fundamentals logoCourse Preview

Temporal Fundamentals

Temporal is a platform for running application code that must survive crashes, restarts, and outages without losing its place. You write a normal program that can take seconds or months to finish, and Temporal records every step so that if the machine running it dies, another one resumes exactly where it stopped. It exists to replace the retry loops, state tables, and reconciliation jobs teams otherwise write by hand to make long, failure-prone processes reliable.

itDistributed systems, messaging, and integration

Don't Panic — Temporal Fundamentals

Here is the corridor version, the one a colleague gives you instead of the homepage. Temporal is a way to run a normal program so that if the machine running it falls over, another machine picks it up at the exact line where it stopped — whether that was one second ago or six months ago. That is the whole pitch. Everything else is bookkeeping.

The problem it solves is depressingly familiar. You have a process — pay someone, onboard someone, provision a server — that takes several steps, calls other services, and occasionally waits days for a human to click approve. To make that survive crashes by hand, you write a state table, retry logic at every call, a queue, a scheduler, and a reconciliation job. None of it is about the actual task, and you maintain it forever. Temporal takes that entire layer and makes it the platform's problem.

Two ideas carry the rest. First, you split your code in two. A Workflow is your process written as ordinary loops and conditionals; an Activity is any single step that touches the outside world, like calling an API or charging a card. Second — and this is the bit that surprises everyone — Temporal does not save a snapshot of your program's memory. It keeps an ordered Event History of everything that happened, and to recover it simply runs your Workflow code again from the top, replaying that history until it catches up.

That replay is where the plausible first guess goes wrong. Because the code is re-run, it must be deterministic: given the same history, it must make the same choices every time. So reading the clock, rolling a random number, or calling the network directly in Workflow code is forbidden — those return something different on the second run and the whole thing derails. Push anything like that into an Activity, which is not replayed. This also means editing a Workflow while it has runs in flight can break them, because old history and new code stop agreeing.

A couple of pieces of vocabulary lie to you if you let them. A "Workflow Task failure" sounds fatal but usually is not — it means one step could not be processed, the step retries, and a fixed redeploy resumes the run. That is very different from the business process itself deciding to fail. Treat the first as the second and you will throw away perfectly recoverable work.

So where should you go from here? The Intro tab is the real overview and the place to actually understand the architecture. The Cheatsheet is where you will live once things click, especially the table of what must never run in Workflow code. Field Notes covers the things that bite in production — chiefly that an Event History has a size ceiling and long-running loops need a trick called Continue-As-New before they hit it. And the Practice tab hands you the temporal command line so you can start a local service and watch a Workflow replay for yourself, which is worth more than any amount of reading.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources