cadence-workflow-orchestration

Cadence Workflow Orchestration

What is Cadence?

Cadence is an open-source fault-oblivious stateful programming model: a durable virtual memory that is not tied to a specific process and preserves full application state — including function stacks and local variables — across host and software failures. You write ordinary code; Cadence guarantees it keeps running (and resumes exactly where it left off) even if the process, host, or network fails.

A Cadence application is composed of Workflows (durable orchestration code) and Activities (the actual side effects: API calls, DB writes, file I/O). Workers are processes you run that host your Workflow and Activity code and poll the Cadence service for work. The Cadence service (frontend/history/matching) is the stateless backend that stores workflow state and durable timers, backed by Cassandra/MySQL/PostgreSQL. External clients (your app code, a CLI, a UI) start, signal, query, and cancel workflow executions via the service's gRPC API.

Official SDKs: Go and Java (production-ready). Community SDKs: Python and Ruby. This skill covers Go and Python client development for local workflow/activity authoring, testing, and debugging. It does not cover production cluster operations (multi-node deployment, Cassandra/ Elasticsearch tuning, cross-DC replication) — see the Operation Guide upstream for that.

Glossary

• Workflow: Deterministic orchestration code that survives crashes by replaying its Event History. Workflows delegate all side effects to Activities.
• Activity: A normal function that performs one side effect (HTTP call, DB write, file I/O). Runs in a standard runtime, is retried on failure, and should be idempotent.
• Worker: A long-lived process that connects to the Cadence service, registers Workflow/Activity implementations, polls a Task List, and executes the tasks it receives.
• Task List: A named queue the Cadence service uses to dispatch Decision Tasks (to run/resume a workflow) and Activity Tasks (to run an activity) to Workers.
• Decision Task: A unit of work delivered to a workflow worker telling it to advance a workflow.
• Domain: A logical isolation boundary for workflows, registered via the CLI or API before you can run anything in it.
• Workflow Execution: One running instance of a Workflow, identified by a WorkflowID and RunID, with an immutable Event History used to recover state after a crash.
• Determinism: A Workflow function must produce the same sequence of decisions on every replay. No direct time.Now(), random numbers, network calls, or unordered goroutine/thread scheduling — use the SDK's deterministic equivalents (workflow.Now, workflow.SideEffect, workflow.Channel, workflow.Selector in Go).
• Idempotency: Activities may run more than once (retries), so their side effects should be safe to repeat.
• Retry Policy: Governs how failed Activity (and, since decision failures are handled differently, Workflow) executions are retried: initial interval, backoff coefficient, max interval, max attempts.
• Heartbeat: A periodic "still alive" signal from a long-running Activity to the service; can also checkpoint progress and deliver cancellation.
• Signal: An async message sent into a running Workflow Execution.
• Query: A synchronous, read-only request against a running Workflow Execution's in-memory state.
• Continue-As-New: A workflow atomically completes its current run and starts a new run with a fresh Event History, used to keep long-running/looping workflows' histories small.
• Cadence Service: The cluster (Frontend / History / Matching / Internal Worker services) that stores workflow state and routes tasks. Locally, a single cadence-server process backed by embedded SQLite is sufficient.