Durable Workflows in 2026: Temporal, Step Functions and When You Need Them

A durable workflow is a multi-step business process that survives crashes, deploys and long waits because its progress lives outside the process that is currently running it. Order fulfillment, KYC reviews and payment retries all need that property once a step can outlive a single request.

Temporal and AWS Step Functions are purpose-built engines for that problem. Many backends never need them: Pub/Sub, a status table and cron already cover fan-out, retries and schedules. This guide separates those cases without pretending a queue is a workflow engine.

Durable workflows at a glance

What "durable" actually means

Durability is not "the queue retries." It means the control state of the process (which step ran, what it returned, which timer is open) is stored so a new worker can continue without redoing completed side effects. Temporal does that by recording an event history and replaying workflow code deterministically. Step Functions does that by advancing a managed state machine and keeping execution history for Standard workflows.

A subscriber that updates orders.status after each message is durable enough for many products. It is not a workflow engine: you own branching, waits measured in days, versioning of in-flight runs and exactly-once side-effect rules yourself.

Temporal: code-first durable execution

Temporal

Temporal is an open source durable execution platform where you write workflows in Go, TypeScript, Java and other SDKs, activities perform I/O, and the Temporal Service stores history and schedules work. On resume, Temporal replays history so workflow code returns to the same logical state, which is why workflow code must stay deterministic and push non-determinism into activities.

You always run workers that poll task queues, including when you use Temporal Cloud. That is the right trade when processes last weeks, wait on human signals or coordinate many services with strict resume semantics. It is the wrong default for a welcome email or a single webhook retry.

AWS Step Functions: managed state machines

AWS Step Functions

Step Functions defines workflows as state machines: Standard workflows run up to one year with exactly-once execution semantics for the workflow and full history in the console, while Express workflows trade that for higher rate and a five-minute maximum. Tasks call AWS services through SDK or optimized integrations, or wait on a callback token for human-in-the-loop steps.

Choose Step Functions when the process is mostly AWS service wiring, you want no workflow workers to operate, and Amazon States Language fits the control flow. Payload size, history retention and AWS-only reach are the constraints to check early; Step Functions is not a portable application runtime.

When Pub/Sub, cron and services are enough

Most backend "workflows" are a publish, one or more subscribers, retries with backoff and a row that says how far the job got. A nightly reconciliation is a cron calling an idempotent API. Those patterns do not need Temporal's replay model or a Step Functions state machine.

Reach for a durable workflow engine when you need several of: waits measured in hours or days, signals from humans or external systems, complex branching that must version safely while old runs are still open, or exact resume of code-level state after every crash. Until then, queues and schedules keep the ops surface smaller.

How Encore covers the common case

Topics, subscriptions and cron jobs in Encore are infrastructure from code for the async paths most products need. You declare them in code, and the platform provisions and deploys them into your own AWS or GCP account.

On AWS, Pub/Sub becomes SNS plus SQS (with dead-letter queues), and Encore provisions an IAM role for the service, per the AWS infrastructure docs. Cron jobs are invoked as API calls by the Encore platform and need no EventBridge rules or extra schedulers in your account. Cron does not run locally; you call the endpoint by hand while developing.

A signup flow that emails the user and schedules a follow-up check:

// user/signup.go
package user

import (
	"context"

	"encore.dev/cron"
	"encore.dev/pubsub"
)

type SignupEvent struct{ UserID int }

var Signups = pubsub.NewTopic[*SignupEvent]("signups", pubsub.TopicConfig{
	DeliveryGuarantee: pubsub.AtLeastOnce,
})

var _ = pubsub.NewSubscription(Signups, "send-welcome", pubsub.SubscriptionConfig[*SignupEvent]{
	Handler: SendWelcome,
})

func SendWelcome(ctx context.Context, e *SignupEvent) error {
	// send email; keep the handler idempotent
	return nil
}

var _ = cron.NewJob("stale-signup-check", cron.JobConfig{
	Title:    "Flag incomplete signups",
	Every:    1 * cron.Hour,
	Endpoint: FlagIncomplete,
})

//encore:api private
func FlagIncomplete(ctx context.Context) error {
	return nil
}

encore run delivers Pub/Sub locally so you can test the welcome path without AWS. The same declarations work from the TypeScript Pub/Sub docs and TypeScript cron docs. Encore is not a Temporal replacement and does not claim Step Functions feature parity: when you need a durable workflow engine with timers, signals and replay, run Temporal (or Step Functions) beside the app. When you need queues, retries and schedules next to the services that publish them, declare them in Encore and deploy to your own cloud.

An AI coding agent can add a topic, subscription or cron job in the same change as the handler and verify the message path with encore run before the deploy creates the AWS resources.

Best fit: Teams whose "workflows" are async service pipelines and schedules in Go or TypeScript on AWS or GCP, and who will adopt Temporal only for the minority of processes that need a durable workflow engine.

When to pick which

Related guides

• How to add Pub/Sub to a Go API
• How to add cron jobs to a Go API
• What is Amazon SQS?
• What is Amazon SNS?
• SNS vs SQS
• Pub/Sub in Go
• Cron jobs in Go