Skip to content

Engineering example

A small workflow. Explicit decisions.

Follow a synthetic replenishment request from validation to a simulated delivery outcome. Run the same implementation here or with Node.js, then inspect the decisions in its source and tests.

Run the example

Synthetic example · not client work

The validation, process-memory state and retry loop execute locally. The receiving system and its responses are simulated. This example is not evidence of a client project or a production outcome.

One request, several useful failure paths

A fictional operations system requests four units of SKU-ALPHA for account SYN-001. A receiving-system adapter returns an accepted, transient or permanent response. No request leaves this page or the local Node.js process.

  1. Validate the contract

    Check the four required fields and their allowed values before reserving an ID or calling the sender.

  2. Reserve the request ID

    Keep its payload fingerprint in this workflow instance. Suppress an identical repeat; reject a different payload under the same ID.

  3. Classify and stop deliberately

    Retry only a classified transient response. Record each attempt, scheduled wait and final outcome.

Run a synthetic scenario

Every run starts with fresh memory. Duplicate and conflict scenarios submit two records inside that run. Delivery is simulated; nothing is sent.

Synthetic input

[
  {
    "requestId": "DEMO-1001",
    "account": "SYN-001",
    "item": "SKU-ALPHA",
    "quantity": 4
  }
]

Observed local result

Choose a scenario and run it to inspect its events.

Decisions you can read and test

The example keeps its contract small so that its behavior can be inspected without a service, credentials or a package installation.

Input contract

Exactly requestId, account, item and quantity. IDs use DEMO- and SYN- prefixes; the item is SKU-ALPHA or SKU-BETA. Quantity must be an integer from 1 to 100. Extra fields and type coercion are rejected.

Duplicate and conflict handling

The request ID identifies a single payload within one workflow instance. A completed repeat reports the previous status without resending. An in-flight repeat is suppressed. An altered payload returns a conflict.

Retry policy

At most three attempts. Transient responses wait 250ms and then 500ms before another attempt. A permanent response stops immediately. An exception or unknown response stops as unclassified failure; it is not automatically retried.

Observable outcomes

Results contain a status, attempt count and ordered event codes. Exhausted, rejected and unclassified failures remain reserved in memory, so repeating the same request does not silently restart delivery.

Download it. Run it. Read the checks.

Use Node.js 22 or later. Save the five files below in one folder, keeping their names. The README explains the simulation and commands. No npm install is required. The browser panel, CLI and checks import the same workflow.mjs implementation.

node workflow-cli.mjs retry
node workflow-cli.mjs all

Run the checks

node --test workflow-checks.mjs

What this example leaves for a real project

  1. State lives only in one JavaScript workflow instance. A reset, reload or new process loses it. Separate instances do not coordinate. There is no durable store, cross-process locking or automatic cleanup.
  2. The sender returns fixed simulated responses. There is no external API, authentication, persistent queue, real delivery acknowledgement or handling of an uncertain remote side effect. This is not an exactly-once delivery guarantee.
  3. A real integration needs agreed ownership, durable identity and retention rules, concurrency behavior, timeouts, reconciliation, operational monitoring and recovery procedures. These choices depend on the receiving system and the project scope.
  4. The records are synthetic and the controls accept no personal or business data. This educational example does not replace permissioned client evidence or establish security, compliance or performance outcomes.

From example to project

Which workflow needs a clearer contract?

A project conversation can start with the systems involved, the request contract, the failure paths and the people responsible for recovery.

Discuss a development project