// the find
temporalio/temporal
Temporal service
Temporal is a durable workflow execution engine—it persists workflow state so that long-running processes survive crashes, retries, and deployments without you writing that recovery logic yourself. It's a fork/evolution of Uber's Cadence, built by the same original authors. Target audience is backend engineers who need to coordinate multi-step, long-running, or failure-prone distributed operations.
- Battle-tested lineage: grew out of Cadence at Uber and has been in production at companies like Stripe and Datadog, so the core execution model has been stress-tested at real scale.
- The event-sourced history approach for workflow state is conceptually sound and means you get full replay/audit of every workflow execution for free—genuinely useful for debugging production incidents.
- Extensive internal API surface with versioned protobuf schemas, mocks generated alongside each service interface, and a dedicated persistence layer abstraction that supports Cassandra, PostgreSQL, MySQL, and SQLite—swapping backends is feasible rather than theoretical.
- CHASM (the new component/state-machine framework visible in the tree) shows active architectural investment: they're decomposing the monolithic workflow state machine into composable pieces, which should make extending the platform less risky over time.
- Operational complexity is steep. Running this yourself means managing Cassandra or Postgres, the frontend/history/matching/worker service roles, and a visibility store—the 'just brew install' path is a dev-mode SQLite shortcut that hides how involved a real deployment is.
- The codebase is enormous and the internal APIs are not stable contracts—if you're embedding or extending the server (not just using it as a client), you'll find yourself chasing internal refactors with no deprecation guarantees.
- Temporal Cloud is the commercially supported path; self-hosted users are second-class in practice. Multi-region replication, geo-redundancy, and some newer features are cloud-first and the self-hosted docs lag noticeably.
- Workflow history size limits are a real footgun: unbounded or very long workflows accumulate history events until they hit a hard cap (~50k events by default), requiring 'continue-as-new' patterns that application developers must implement manually—it leaks an internal constraint into business logic.