Skip to main content

How to explain Temporal

There are many ways to introduce and teach Temporal based on your background. Temporal doesn't have a monopoly on explaining Temporal.

Here, we list great blogposts and videos by Temporal staff and users that might be helpful in increasing your understanding or convincing your team.

If you have made a tutorial or explanation of Temporal, please submit them here so that others can find it!

Press announcements

Our Series A and Series B press releases provided high-level descriptions of Temporal. These might be helpful for non-technical or technical-adjacent audiences:

How Temporal works

See the Concepts topic about Temporal.


Designing a Workflow Engine from First Principles0:23MaximMar 31, 2021
Building Reliable Distributed Systems (slides)1:37LorenAug 16, 2022
Fault Tolerant, Distributed Microservices Orchestration with Temporal (slides)0:35Maxim & TihoFeb 23, 2022
Introduction to Temporal Architecture0:16 + Q&ADominikFeb 21, 2022
Temporal in 7 Minutes - The TL;DR Intro0:07swyxFeb 14, 2022
State of Affairs or Affairs of State (Stateless vs Stateful, Orleans vs Temporal)0:35SergeyNov 10, 2021


Creating Resilient Applications with Temporal0:41OSS Startup PodcastMaxim & DominikAug 5, 2022
Temporal0:40contributorMaxim & DominikJun 22, 2022
Temporal0:50FlagsmithMaxim & RylandJun 19, 2022
Run your microservices in no-fail mode0:22Stack Overflow PodcastMaxim & DominikJun 14, 2022
Temporal vs the Serverless Ecosystem1:05Serverless Chats PodcastswyxFeb 14, 2022
Temporal Overview (starts at 0:15)0:33MongoDB PodcastswyxDec 6, 2021
Origin story, Choreography vs Orchestration, and Tips0:21Break Things on Purpose (Gremlin)Maxim & SamarOct 5, 2021
Workflow Engine with Maxim Fateev0:56Software Engineering DailyMaxim
Temporal Developer Experience (video)0:56Devtools.fmswyxSep 10, 2021
Temporal Origin Story0:41OSS Startup PodcastMaximAug 5, 2021
Temporal Product: Managing State0:53Software Engineering DailyRylandMay 8, 2021


Temporal's previous iteration was Cadence, which shares a lot of the same design principles (see the difference between Cadence and Temporal).

Why Workflow Orchestration

  • Build a Reliable System in a Microservices World on Snap Engineering Blog

    Building a reliable “simple” microservices system is not simple. It often requires engineers to think through edge cases and write boilerplate error handling logic in any places where systems are integrated. Beyond error handling, in certain systems like payment or billing systems if we are not able to track the application states, it could mean money loss or other worse consequences.

  • How Chronosphere built a deployment system with Temporal on Chronosphere Blog

    Temporal has enabled Chronosphere to more safely and reliably automate complex, long-running tasks. It has also enabled us to easily reuse common activities across different types of workflows. For example, the helper that pauses a Workflow if an alert fires can be used by our deployment system and capacity tooling with just a few lines of code. This empowers engineers across different teams to ship features quickly while meeting our rigorous standards for safety and customer trust.

  • Dealing with Failure on

    Dealing with failures is the most important aspect of any system. Oftentimes, it is what stands between a product that runs as expected and one that keeps producing surprises and causing investigations. When done right, handling of failures is what differentiates a professional from an amateur.

  • Microservices Architecture With on the SpiralScout blog

    The Temporal Workflows engine is incredibly powerful and provides full control over workflows, including retries, timeouts, backpressure, and the parallel execution of activities. Workflows can be written in most programming languages and include checks, conditions, and sequences of execution.

  • The macro problem with microservices on the StackOverflow blog

    In just 20 years, software engineering has shifted — from architecting monoliths with a single database and centralized state — to microservices where everything is distributed across multiple containers, servers, data centers, and even continents. Distributing things solves scaling concerns, but introduces a whole new world of problems, many of which were previously solved by monoliths.

  • Temporal Tackles Microservice Reliability Headaches on the New Stack blog

    Using code, it aims to hide the complexity of building with microservices across distributed systems. It employs durable virtual memory not linked to a specific process that preserves the application state despite a whole range of possible failures.

  • Polyglot Microservices with gRPC on the Red Hat blog

    Temporal's benefit is that developers can implement activities easily in a variety of languages. Each activity sends its mission-critical data to a gRPC client that forwards it to a gRPC server. The gRPC server then passes all that data from those language-specific tasks onto the backend Temporal service. Temporal does the heavy lifting of ensuring execution in the face of danger, such as a momentary network outage or an unexpected slowdown in disk access.

  • Using Temporal to outsource operational concerns by Jon Cheng

    Unlike Step Functions and Conductor, the entire Temporal Workflow is defined by code. This makes the behavior of the entire program easier to understand. Moreover, for users of the Go or Java SDK, the users may take advantage of the compiler to catch a wide array of errors as well as improve quality in a large team. Then code is guaranteed to execute as you specified on the Temporal Platform. All of the operational stuff: Retries, recovery, persistent state, message queues, scaling, work distribution, tracing and monitoring are all handled by the platform itself. This really is amazing stuff! If C simplified writng portable code, and GC simplified memory management, and serverless simplified scalable architectures, Temporal simplifies implementing a computer program on top of a fragile, distributed system.

  • A comparison of Temporal Workflows vs Actor Toolkits like Akka and Vert.X by Manuel Bernhardt

    Just like actors provide the illusion of single-threaded, sequential execution, workflows provide the illusion of persistent method calls.

External content

Note: Each of our SDK docs have a Hello World and Run Your First App tutorial!

Temporal users

  • Mitchell Hashimoto, Hashicorp

    So every "cluster create" is a long-running Cadence operation. Once complete, this kicks of a variety of Cadence workflows per cluster that run forever until it is destroyed. This lets you have a central "event loop" per cluster. For example: a "snapshot" triggers an event in the main event loop for a cluster, which ensures that no other ops (upgrades, etc.) are running at the same time, kicks off the snapshot job, then continues. We have long (multi-day/week) sleeps in the main event loop that wake up to renew TLS certs. And if any of the Cadence workers die, they come back up and continue right where they left off.

  • Software Delivery Building Blocks at Datadog by Jacob LeGrone and Kevin Devroede (Datadog) (starting at 6min 30s)

    Temporal lets [Datadog]:

    1. write "fault oblivious" stateful control flow and business logic, in the programming language of your choice,
    2. respond to external events,
    3. support very long running operations,
    4. Communicate with 3rd party services
  • Building Reliable Workflows: Cadence as a Fallback for Event-Driven Processing by Alan Lin (DoorDash)

    Moving to a fully asynchronous-based event driven processing system will in our case result in big performance gains as we move off a synchronous processing model for one of our core flows. Eventually... we will eventually build enough confidence in the platform to use it solely for our primary delivery creation flow. This will bring us massive gains in developer productivity due to its ease of use and abstraction of fussy details.

  • Reuben Bond, Microsoft

    "Certain programming models allow more to be in the lower layers, not exposed to the application, due to their semantics and failure models. Eg, as was mentioned with Temporal - the app code is failure oblivious and retries/backoff/jitter/durability can be handled below"

  • Richard Kettelerij, Mindloops

    "Pretty awesome tech. Allows you to express long running processes in a fault tolerant way using Java (or Go) without explicit timers, queues, polling, etc. Like in this example: "pause" a method for 30 days, something you wouldn't normally do."

  • Ido Shamun,

    "A fault-tolerant sleep statement is what caught my attention and convinced me to try @temporalio. This is so fun to use!"

  • Guillermo Rauch, Vercel

    "Temporal does to backend and infra what React did to frontend. If you're in the React world, you've forgotten about manually adding and removing DOM elements, updating attributes and their quirks, hooking up event listeners… It's not only been a boost in developer experience, but most importantly in consistency and reliability. In the backend world, this reliability problem is absurdly amplified as monoliths break into SaaS services, functions, containers… You have to carefully manage and create queues to capture each side effect, ensure everything gets retried, state is scattered all over the place. Temporal's engine is quite complex, much like React's, but the surface exposed to the developer is a beautiful "render()" function to organize your backend workflows."

Community distros


Everything that doesn't fit above goes here.

If you can't find what you need, don't hesitate to ask on the Temporal Slack workspace or search in the Temporal Community Forum, where you can find answers to common questions like the following: