Examples

Example 1: Multi-Channel Order Notification

When an order is confirmed, simultaneously send an email receipt, an SMS alert, and a Slack channel notification. All three channels are independent and should run concurrently. A failure on one channel (e.g., SMS provider down) should not block the others.

{
  "node_type": "ParallelFork",
  "node_id": "NotifyAllChannels",
  "config": {
    "fail_fast": false,
    "max_parallelism": 0
  },
  "connections": {
    "success": [
      "SendOrderConfirmationEmail",
      "SendOrderSmsAlert",
      "PostOrderSlackMessage"
    ]
  }
}

// All three nodes start simultaneously.
// Each receives full order context including orderId, customer details.
// ParallelJoin waits for all three before proceeding.

Expected outcome: All three notifications are dispatched concurrently, reducing total notification time from ~3 seconds to ~1 second. If SMS fails, email and Slack still complete — the Join node records the SMS failure in lane results.

Example 2: Concurrent Customer Profile Enrichment

Enrich a customer profile from three independent data sources simultaneously. All three results are needed to assemble the complete profile, so fail_fast is enabled.

{
  "node_type": "ParallelFork",
  "node_id": "EnrichCustomerProfile",
  "config": {
    "fail_fast": true,
    "max_parallelism": 0
  },
  "connections": {
    "success": [
      "CallCreditScoringAPI",
      "CallFraudRiskAPI",
      "CallLoyaltyProgrammeAPI"
    ]
  }
}

// Each API call runs independently.
// If any API returns an error, fail_fast cancels the others.
// ParallelJoin merges: lane_0_creditScore, lane_1_riskScore, lane_2_loyaltyPoints

Expected outcome: All three API calls fire simultaneously. If all succeed, the Join assembles the complete enriched profile. If any fails, the remaining calls are cancelled and the workflow routes to an enrichment error handler.

Example 3: Rate-Limited Parallel API Calls

Fan out to 8 data processing lanes but limit to 3 concurrent executions to respect API rate limits. Lanes 4-8 queue and execute as the earlier lanes complete.

{
  "node_type": "ParallelFork",
  "node_id": "ProcessDataBatch",
  "config": {
    "fail_fast": false,
    "max_parallelism": 3
  },
  "connections": {
    "success": [
      "ProcessSegmentA", "ProcessSegmentB", "ProcessSegmentC",
      "ProcessSegmentD", "ProcessSegmentE", "ProcessSegmentF",
      "ProcessSegmentG", "ProcessSegmentH"
    ]
  }
}

Expected outcome: Segments A, B, and C start immediately. As each completes, the next queued segment starts. At most 3 segments are processing at any given time, staying within the API rate limit. Total time is significantly less than sequential processing while remaining within rate constraints.

Example 4: Parallel Document Generation

Generate four output documents from a single order record simultaneously: customer invoice, shipping label, warehouse pick list, and supplier remittance advice.

{
  "node_type": "ParallelFork",
  "node_id": "GenerateOrderDocuments",
  "config": {
    "fail_fast": false,
    "max_parallelism": 0
  },
  "connections": {
    "success": [
      "GenerateCustomerInvoice",
      "GenerateShippingLabel",
      "GenerateWarehousePickList",
      "GenerateSupplierRemittance"
    ]
  }
}

// Each generator uses orderId from the shared context.
// Each produces a document URL stored in its lane's results.
// ParallelJoin collects:
//   lane_0_invoiceUrl, lane_1_shippingLabelUrl,
//   lane_2_pickListUrl, lane_3_remittanceUrl

Expected outcome: All four documents are generated concurrently. The total generation time equals the slowest document renderer, not the sum. After the Join, all four document URLs are available for dispatch to the relevant recipients.