Temporal provides a unified backend for automatically managing implicit application state that is normally stored in transient queues, databases etc. Furthermore, Temporal does this without explicitly requiring the developer to think about and manage the state themselves. This means developers spend way more time building stuff that actually matters, and less time writing buggy reliability code.

I personally find the best way to explain it is with an analogy. Back in the late 90s many developers built applications with C and therefore had to manage their own memory. For a long time, this was not wasted effort as it was the only real option. But then, Java came around and offered an experience where developers didn't have to manage their memory. And for the majority of apps, the performance and capabilities of Java were more than sufficient. At this point, writing the average application in C meant you were doing a serious amount of undifferentiated work. Furthermore, most developers weren't that great at memory management so choosing to do it by hand meant more work for a worse result.

The value proposition of Temporal is nearly identical, but instead of manually managing memory with C, developers are manually managing state using queues, CRON services, databases and more. The result is a bunch of time spent doing undifferentiated things that a computer would have done better anyway.

Temporal is a workflow engine for managing distributed state. It abstracts away queues, databases, schedulers, state machines, load balancers/gateways and makes it so you don't have to be a distributed systems expert to get this right.

To me there are four levels of appeal:

1. standardized, declarative system for timeouts and retries <-- most users start here

2. event sourced, highly fault tolerant internal architecture ---> we even like the term "fault oblivious" - when you write workflow code you can assume that it is robust to downtime in external APIs, or Temporal Server or Temporal Workers, the thing just keeps going until it hits a timeout or an actual application failure!

3. idiomatic SDKs for "workflows as code" -> no need to learn some JSON or YML based DSL, use all familiar software tooling

4. horizontally scalable architecture for every part of the system (key differentiator vs handrolled systems... although i'm not saying you should prematurely scale of course, just saying this architecture lets you scale without replatforming)

Some projects that we get compared to (although of course we're not 1:1 competitors): Apache Airflow, AWS Step Functions, Argo Workflows, Sidekiq, BullMQ

My 7 min intro: https://www.youtube.com/watch?v=CQhUL5RogXI

Architecture principles (23mins) https://docs.temporal.io/blog/workflow-engine-principles

Full blogpost: https://www.swyx.io/why-temporal/

The use case is basically any kind of temporally-distributed workflow that you might use something like Airflow for, or else otherwise hack together with some combination of event buses, temp tables, and cronjobs. Its main charm is that you define the logic in code rather than templates, so you can intermix business logic directly into the workflow.

ctrl + F to here "Temporal is a new kind of platform. It’s not a database, cache, queue, or a means to run your code. It’s a runtime for distributed applications that transparently manages their state at any scope and scale. By externalizing state to a generalized platform like Temporal, application teams get to outsource the majority of cross-cutting concerns presented by cloud applications. In doing so, applications become" if you dont want to read the whole thing

From my take, an interesting way of dealing with scalable workflows and batch jobs. But I need to read more into it.

It's like computer hibernation, but for a process that runs on a whole distributed system instead of on a single computer. As programmer of that process, you just focus on writing your business logic with the assumption that each step will eventually complete, and not have to worry about power loss/network loss/machine loss while your process is running. This way, it's much easier to reason about and focus on the thing you care the most: your business.