Parallel
Run child blocks concurrently inside a container
The Parallel block is a container block in TradingGoose that runs child blocks concurrently.
Parallel blocks are container nodes. Drag child blocks inside the parallel on the canvas. Incoming edges enter through Parallel Start, and child outputs reconnect to Parallel End before the workflow continues outside the container.
Overview
The Parallel block enables you to:
Distribute work: Process multiple items concurrently
Speed up execution: Run independent operations simultaneously
Handle bulk operations: Process large datasets efficiently
Aggregate results: Collect outputs from all parallel executions
Configuration Options
Parallel Type
Choose between two types of parallel execution:
Count-based Parallel - Execute a fixed number of parallel instances.
Use this when you need to run the same operation multiple times concurrently.
Example: Run 5 parallel instances
- Instance 1 ┐
- Instance 2 ├─ All execute simultaneously
- Instance 3 │
- Instance 4 │
- Instance 5 ┘Collection-based Parallel - Distribute a collection across parallel instances.
Each instance processes one item from the collection simultaneously.
Example: Process ["task1", "task2", "task3"] in parallel
- Instance 1: Process "task1" ┐
- Instance 2: Process "task2" ├─ All execute simultaneously
- Instance 3: Process "task3" ┘How to Use Parallel Blocks
Creating a Parallel Block
- Drag a Parallel block from the toolbar onto your canvas
- Configure the parallel type and parameters
- Drag the child blocks that should run in parallel inside the container
- Connect incoming flow to Parallel Start, and connect child outputs back to Parallel End before continuing outside the container
Accessing Results
After a parallel block completes, you can access aggregated results:
<parallel.results>: Array of results from all parallel instances
Example Use Cases
Batch API Processing
Scenario: Process multiple API calls simultaneously
- Parallel block with collection of API endpoints
- Inside parallel: API block calls each endpoint
- After parallel: Process all responses together
Multi-Model AI Processing
Scenario: Get responses from multiple AI models
- Collection-based parallel over a list of model IDs (e.g., ["gpt-4o", "claude-3.7-sonnet", "gemini-2.5-pro"])
- Inside parallel: Agent's model is set to the current item from the collection
- After parallel: Compare and select best response
Advanced Features
Result Aggregation
Results from all parallel instances are automatically collected:
// In a Function block after the parallel
const allResults = input.parallel.results;
// Returns: [result1, result2, result3, ...]Instance Isolation
Each parallel instance runs independently:
- Separate variable scopes
- No shared state between instances
- Failures in one instance don't affect others
Limitations
Container blocks (Loops and Parallels) cannot be nested inside each other. This means:
- You cannot place a Loop block inside a Parallel block
- You cannot place another Parallel block inside a Parallel block
- You cannot place any container block inside another container block
While parallel execution is faster, be mindful of:
- API rate limits when making concurrent requests
- Memory usage with large datasets
- Maximum of 20 concurrent instances to prevent resource exhaustion
Parallel vs Loop
Understanding when to use each:
| Feature | Parallel | Loop |
|---|---|---|
| Execution | Concurrent | Sequential |
| Speed | Faster for independent operations | Slower but ordered |
| Order | No guaranteed order | Maintains order |
| Use case | Independent operations | Dependent operations |
| Resource usage | Higher | Lower |
Inputs and Outputs
Parallel Type: Choose between 'count' or 'collection'
Count: Number of instances to run (count-based)
Collection: Array or object to distribute (collection-based)
parallel.currentItem: Item for this instance
parallel.index: Instance number (0-based)
parallel.items: Full collection (collection-based)
parallel.results: Array of all instance results
Access: Available in blocks after the parallel
Best Practices
- Independent operations only: Ensure operations don't depend on each other
- Handle rate limits: Add delays or throttling for API-heavy workflows
- Error handling: Each instance should handle its own errors gracefully