Why architecture matters here
The core problem orchestration solves is that a multi-step process has state that must outlive any single machine. Consider an order-fulfillment flow: charge the card, reserve inventory, schedule shipment, notify the customer. Written as a plain function, the flow's position lives only in that function's stack and local variables. If the process is killed after charging the card but before reserving inventory — a deploy, an out-of-memory kill, a zone outage — that state evaporates. You are left with a charged customer, no reservation, and no record of what happened. Every workaround (write your own status table, poll for stuck orders, build a reconciliation job) is a hand-rolled reimplementation of durable execution.
Cloud Workflows makes the state machine explicit and the state durable. The workflow definition is the state machine: each step is a named state, and the engine always knows which state a given execution is in because it persisted that fact. When a step completes, its result and the next step are written to the state store before execution continues. A failure between steps is not a lost process; it is a paused one that resumes from the last durable checkpoint. This turns 'what happens if it crashes here?' from a design headache into a property the platform guarantees.
Three capabilities follow from durable, declarative orchestration. Reliability by construction: retries and error branches are declared per step, so transient failures are handled uniformly instead of ad hoc, and the happy path stays readable. Long-running processes without long-running compute: a workflow can wait hours or days for a human approval or an external event via a callback, consuming no compute while it waits, then resume instantly — impossible with a function that must return in minutes. Observability: because the engine records every step, every execution has a complete, queryable history — what ran, what it returned, what failed, and how long each step took.
The cost is a different mental model and real limits. You are writing a declarative flow, not imperative code, so control flow, data passing, and error handling use the workflow's own syntax. And the engine has quotas — on execution duration, step count, payload sizes, and concurrent executions — that shape what belongs in a workflow versus what belongs in the services it calls. Knowing where that boundary sits is what separates a workflow that scales cleanly from one that fights the platform.
The architecture: every piece explained
Top row: from definition to running execution. The definition is a YAML or JSON document listing steps: assignments, HTTP calls, conditionals, loops, and control constructs, written in the Workflows expression language. A trigger starts an execution — an HTTP request, Cloud Scheduler on a cron, an Eventarc event (a file lands in a bucket, a Pub/Sub message arrives), or a direct API call. The execution engine is the managed interpreter: it reads the definition, evaluates each step, and drives the flow. The state store is the durable memory: after each step it persists the current position and all variables, which is what makes execution resumable.
Middle row: the building blocks that make steps useful. The HTTP connector lets a step call any endpoint — a Cloud Run service, a Cloud Function, a GCP API (via authenticated connectors that handle OAuth automatically), or any external REST API. Retry and backoff policies attach to a step or a try-block, so a transient 503 is retried with exponential backoff without any custom code. try/except catches errors and branches — map a specific error to a compensating action, a fallback call, or a clean failure. Parallel and iteration constructs run branches concurrently or loop over a collection, so a fan-out (call ten services at once, or process each item in a list) is a few lines.
Bottom row: the long-running and integration surface. Callbacks and waits let a workflow pause: it can sleep for a duration, or create a callback endpoint and block until an external system (a human approval UI, another service) posts to it — the execution consumes no compute while parked and resumes with full state on the callback. The targets are the services the workflow orchestrates: Cloud Run and Cloud Functions for custom logic, GCP APIs for managed operations, Pub/Sub for emitting events, and arbitrary APIs for third parties. The workflow is the conductor; these are the instruments.
Bottom strip: the operational surface. Every execution emits structured logs (Cloud Logging) with per-step entries; step latency, retry rate, and error branches are all observable. Quotas — max execution time, steps per execution, concurrent executions, and payload sizes — bound what a single workflow may do. Idempotency is the workflow author's responsibility at every call that mutates state, because retries and resumptions can re-invoke a step. And cost is per-step, so step count and call volume translate directly into spend. The diagram shows the definition feeding the engine, the engine checkpointing to the state store after each step, and the building blocks fanning out to real targets.
End-to-end flow
Trace an order-fulfillment execution. An Eventarc trigger fires when a new order lands in a Pub/Sub topic; the engine starts an execution with the order payload as input and immediately persists step 0. Step 1 assigns variables (order id, customer, amount). Step 2 is an HTTP call to the payment service with a retry policy: on a transient 503 it backs off and retries up to three times; on success it stores the charge id. The engine checkpoints the charge id to the state store before moving on — so even if the next step crashes the platform, the charge is recorded and will not be repeated.
Step 3 is a parallel block: reserve inventory and pre-book the carrier at the same time, each an HTTP call to a different Cloud Run service. Both branches run concurrently; the engine waits for both, checkpoints their results, and continues. Step 4 is a try/except: attempt to schedule the shipment. Suppose the carrier API returns a hard 422 (address unserviceable). The except block catches it, branches to a compensation path — refund the charge via the payment service, release the inventory reservation — logs a structured failure, and ends the execution in a well-defined 'cancelled' state. No orphaned charge, no leaked reservation.
Take the happy path instead. Shipment scheduled, step 5 creates a callback and pauses: the workflow is now waiting for the warehouse system to confirm pick-and-pack, which may take hours. The execution consumes no compute; its state sits durably in the state store. When the warehouse posts to the callback URL, the engine resumes exactly at step 5 with all prior variables intact, records the confirmation, and proceeds to step 6: publish an 'order shipped' event to Pub/Sub and send the customer notification via another call.
Now inject a platform failure mid-run: right after the payment charge is checkpointed but before inventory is reserved, the execution's underlying infrastructure is disrupted. Because the engine persisted state after step 2, the execution resumes at step 3 — it does not re-run the payment. This is durable execution earning its keep: the checkpoint boundary is the recovery unit, and the only re-execution risk is within a single step that failed after its side effect but before its result was persisted — which is precisely why each mutating call must be idempotent (an idempotency key on the charge, a conditional reservation). The final execution history in Cloud Logging shows every step, its inputs, outputs, retries, and latencies — a complete, auditable record of the process.