AWS Event-Driven State Machines for Sequenced Gates

Step Functions, EventBridge Scheduler, and the idempotent confirmation store across SAP and DOP.

A workflow that waits days for an external signal and must survive a reboot — where should its memory live?

The Ops lesson built a four-leg exit protocol. The Python lesson encoded it as a guarded state machine. This lesson runs that machine on AWS, where the legs become Step Functions states, the daily signal arrives from a scheduler, and the fake-reversal filter becomes an idempotent write to a DynamoDB conditional store. SAP asks how to architect it for availability and cost; DOP asks how to deploy, observe, and recover it.

§ IFrame

A sequenced confirmation gate is a long-running workflow. It spans days, waits for external signals, and must survive a process restart without losing its place. Holding state in memory is the wrong architecture on AWS — a Lambda times out, an EC2 instance reboots, and the sequence is lost. The right architecture externalizes the state into a managed service that persists the position and resumes exactly where it left off.

AWS Step Functions is that service. A state machine definition in Amazon States Language holds the legs as states, the transitions as Next fields, and the wait-for-signal behavior as task tokens. The workflow's position lives in the service, not in any compute instance. This is the architectural point both exams test from opposite sides.

§ IIDomain Foundations

Event-driven workflow as the shared foundation

An event-driven architecture decouples the producer of a signal from the consumer that acts on it. Reis and Housley frame the pattern (Fundamentals of Data Engineering, Part I, p. 120): events flow through a broker, and consumers react without the producer knowing who reacts. The exit gate is event-driven by nature — the ETF flow publication, the stablecoin inflow reading, and the price reclaim arrive on different clocks, and the workflow reacts to each as it lands.

The hard part of any event-driven gate is exactly-once handling. Kleppmann's treatment of stream-processing fault tolerance (Designing Data-Intensive Applications, Ch 11, p. 483) is the foundation: when a consumer can crash and retry, the same event may be delivered more than once, and the system must produce the same result as if it were delivered once. Akidau sharpens it (Streaming Systems, Ch 5, p. 172): true exactly-once delivery is impossible, so systems achieve exactly-once effects through idempotent operations keyed on a deduplication identifier. This is the fake-reversal filter at the infrastructure layer — a redelivered publication must not count as a second confirming print.

§ IIISAP Flavor — Architecting for Availability and Cost

Standard versus Express workflows. Standard workflows run up to a year, are durable, and bill per state transition. Express workflows run up to five minutes and bill on duration and memory. A multi-day exit gate is a Standard workflow without question — the durability and long runtime are the requirement, and the low transition count makes the per-transition cost trivial.

The wait pattern. A leg that waits for a daily publication should not poll. The architecture uses the task-token integration: the machine pauses at a .waitForTaskToken task, an EventBridge rule fires when the publication lands, a Lambda validates the signal and calls SendTaskSuccess or SendTaskFailure with the token. The workflow consumes zero compute while it waits — no idle instances, no polling bill, managed durability.

The confirmation store. The idempotent confirmation lives in DynamoDB. Each write uses a conditional expression keyed on (leg, publication_date) so a redelivered event fails the condition and is absorbed. On-demand capacity suits the bursty, low-volume pattern, and a global table gives multi-region durability if the gate must survive a regional event.

§ IVDOP Flavor — Deploying, Observing, Recovering

Deploying the definition. The state machine is infrastructure. Its ASL definition ships as code through CloudFormation or the CDK, version-controlled, deployed through a pipeline. A change to a leg's threshold is a code change with a review and a deploy, not a console edit.

Observing the execution. Step Functions emits execution history natively, and every transition is a CloudWatch event. The instrumentation routes execution-status changes to EventBridge, alarms on ExecutionsFailed, and ships history to CloudWatch Logs for audit. A gate that advances to a leg it should not have reached is detectable because every transition is a logged, queryable event. This reaches back to the 06-23 CloudTrail Lake lesson — the same audit-first posture, now applied to workflow transitions.

Recovering a stuck execution. A leg waiting on a task token can hang if the token-holder never responds. The discipline sets HeartbeatSeconds and TimeoutSeconds on the wait task so a stuck leg fails into a Catch state rather than waiting forever. The Catch block routes the failure to a recovery branch that resets the leg — the cloud expression of the Python machine's reset edge.

§ VWorked Scenario

A flow publication lands and triggers the gate. EventBridge matches the event and invokes the validator Lambda. The Lambda writes the signal to DynamoDB with a conditional put keyed on (FLOW, 2026-06-30).

PutItem
  TableName: exit-confirmation-store
  Item: {leg: FLOW, pub_date: 2026-06-30, positive: true, funds: 2, inflow_usd: 90000000}
  ConditionExpression: attribute_not_exists(pub_date)

If the publication is delivered twice by a retry, the second PutItem fails the attribute_not_exists condition and the Lambda treats it as a successful no-op. The leg counts one confirming print, not two. The idempotent store is the fake-reversal filter's infrastructure twin: it refuses to let a redelivery masquerade as a second observation.

The Lambda then reads the leg's confirmation count. If Leg 1 has now seen two genuine consecutive publications, it calls SendTaskSuccess and the workflow transitions from the flow-wait state to the capital-wait state. If the count is one, the Lambda calls nothing and the workflow stays paused, costing nothing, until tomorrow's publication. A failed print calls SendTaskFailure, the Catch block resets the leg, and the workflow returns to the held-regime state.

§ VIConnection to Today's Ops + Dev Lessons

The Ops lesson defined the four legs and the rule that none clears out of order. The Python lesson encoded that as a transition table where illegal moves are absent edges. This lesson runs the same machine as a Step Functions Standard workflow: the ASL Next fields are the table's edges, the .waitForTaskToken tasks are the legs waiting on signals, the DynamoDB conditional put is the confirmation counter's deduplication. Three lessons, one machine at three altitudes — trading logic, in-process encoding, managed cloud execution.

§ VIIIClosing

The exit gate is a long-running, event-driven, fault-tolerant workflow, and AWS has a service shaped exactly to that sentence. Step Functions Standard holds the sequence, EventBridge delivers the signals, DynamoDB conditional writes enforce idempotency, and Catch blocks recover the stuck legs. SAP designs it for availability and cost; DOP deploys, observes, and recovers it. Same machine, two exams, one architecture.

Draw the state machine before you draw the diagram. The legs are the states; the rest is plumbing.