State Machines

A state machine describes a process through states, transitions, and the conditions or events that trigger those transitions. An execution starts in an initial state, progresses according to defined rules, and may reach a successful or failed terminal state. States can represent business conditions, such as awaiting payment, or workflow operations, such as invoking a service, waiting for a callback, or choosing the next branch. The model defines which transitions are valid instead of allowing arbitrary changes to process status.

In cloud systems, a workflow orchestrator can execute this model across independently deployed services. The orchestrator tracks progress and decides what should happen next, while workers perform business operations. For example, an order workflow might validate a request, reserve inventory, authorize payment, and request shipment. A payment rejection takes a different path from a temporary payment-service timeout. Separating coordination from task implementation avoids embedding the entire workflow in one function or distributing its sequencing logic across many services.

Durable orchestration is especially useful when a process must survive worker failures or wait for external events. A document-processing workflow might submit a batch job, wait for completion, request human approval, and then publish the result. A suitable orchestration engine persists enough execution information to continue without keeping one application process running throughout the wait. Persistence, execution duration, callback support, and recovery guarantees depend on the engine and workflow type; they are not automatic properties of every state-machine implementation.

Resilience requires explicit failure paths. Retry transient failures with bounded attempts and backoff, set task and workflow timeouts, and route unrecoverable errors to handling or compensation states. If inventory reservation succeeds but payment ultimately fails, a compensating operation can release the reservation. This is not an automatic database rollback: each service owns its data, and compensation is another business operation that can itself fail and require recovery.

Retries and durable execution do not guarantee exactly-once business effects. A worker might complete a payment operation before its response is lost, causing a retry to repeat the request. Use idempotency keys, deduplication records, or conditional updates to prevent duplicate effects. Keep execution data bounded, pass references to large objects rather than embedding them, and limit parallelism so a scalable orchestrator does not overwhelm downstream APIs or databases.

Orchestration and messaging solve different problems. A queue buffers work and decouples producers from consumers, but it does not by itself define a multi-step process with branching, joins, and compensation. Event-driven choreography lets services react independently to events; orchestration makes the overall sequence explicit. They can be combined, with a state machine dispatching queued work and waiting for completion signals.

For architecture questions, choose workflow orchestration when requirements emphasize ordered tasks, conditional branches, parallel work, callbacks, and centralized failure handling. AWS Step Functions is one implementation, not the definition of the concept. Evaluate execution semantics, service quotas, transition or execution costs, observability, and provider coupling. A state machine improves coordination, but it does not remove downstream capacity limits or make a distributed workflow a single atomic transaction.