Skip to content

Martini Synchronous vs Asynchronous Workflows - Understanding Workflow Patterns in Martini

Overview

Martini workflows follow two distinct patterns based on the nodes you use: synchronous workflows that execute continuously from start to finish, and asynchronous workflows that pause to wait for external events like scheduled times, events, etc. Understanding these patterns will help you understand and design solutions that match your real-world business processes, whether you're building instant-response APIs or multi-day workflows.

What You Will Learn

  • What synchronous and asynchronous workflow patterns look like in Martini
  • Real-world examples of what you can build with each pattern
  • How to choose the right pattern for your use case

When To Use This

Use this guide when:

  • You're designing a new workflow and want to understand execution patterns

Getting Started

New to Martini workflows? Start here:

  1. Choose your pattern based on your need:
  2. Building an API? → Start with Synchronous Workflow Pattern

  3. Need to wait for responses which can take more than a few minutes to days? → Jump to Asynchronous Workflow Pattern

  4. Follow the enterprise scenario that matches your use case

  5. Use the Pattern Recognition Guide to verify your approach

Time to complete: 15-30 minutes depending on complexity

Prerequisites

Synchronous Workflow Pattern

Workflows that execute continuously from start to finish without interruption. They process input data through each step sequentially until they complete their task or return a result.

Getting Started with Synchronous Workflows

Example of a synchronous workflow:

1
2
[Start Trigger Node] → [Map Node] → [Database Node] → [Map Node]
(continuous execution, no pauses)

Breaking down this example:

  • Start Trigger Node - Receives the incoming request (API call, manual trigger)
  • Map Node - Transforms input data into the format needed for database query
  • Database Node - Executes database query to fetch or update data
  • Map Node - Formats the final response with success status and updated data

Each node executes immediately after the previous one completes, with no waiting or pausing points.

Enterprise Scenario: Customer Data Update API

A CRM system needs to instantly update customer information and confirm the change:

1
2
[API Request (Start Trigger Node): Customer Update] → [Map Node: Format Customer Data] → [Database Node: Update Customer Record]
→ [Map Node: Return Success Response]
  • Sales rep submits customer information update (Sends an API Request which triggers the workflow via the Start Trigger Node)
  • System validates and formats customer ID and new information (Map Node)
  • Updates customer record with new information in CRM database (Database Node)
  • Creates success response with updated customer details and confirmation message (Map Node)

This synchronous pattern ensures that when customer information is updated, the change is processed immediately and the requesting system receives instant confirmation with the updated customer data.

When Synchronous Workflows Won't Work: Email Response Example

Consider this scenario where you need to send an email and wait for a reply:

1
2
3
❌ FAILED SYNCHRONOUS APPROACH:
[Start Trigger Node] → [Invoke Function Node: Send Email] → [Script Node: Check for Reply] → [Map Node: Process Reply]
                                        ↑ (This will fail - no reply exists yet!)

Why this fails:

  • The email is sent instantly, but replies take time (minutes, hours, or days)
  • The "Check for Reply" script runs immediately after sending, finding nothing
  • Synchronous workflows can't pause and wait for external responses
  • You'd need to implement complex polling or timeout logic

The solution: Use the Asynchronous Workflow Pattern instead:

1
2
3
✅ WORKING ASYNCHRONOUS APPROACH:
[Start Trigger Node] → [Invoke Function Node: Send Email] → [Wait Event Node: Email Reply] → [Map Node: Process Reply]
                                        ↓ (Pauses here until reply arrives)

This demonstrates why choosing the right pattern matters - some business processes require waiting, which only asynchronous workflows can handle efficiently.

Synchronous Workflow Pattern Key Characteristics

Characteristic Description
Execution Runs continuously from start to finish without interruption
Duration Seconds to minutes
Resources Holds execution thread and memory throughout
State Kept in memory, no persistence needed
Best For APIs, data transformations, instant responses

How Synchronous Workflows Execute in Martini

When you start a synchronous workflow:

  1. Martini receives the trigger (Start Trigger Node, Email Trigger Node, Scheduler Trigger Node, Webhook Node, or other trigger types)
  2. Executes each node sequentially
  3. Returns result when complete
  4. Releases all resources immediately

Resource behavior: Execution thread stays active, memory held until completion, database connections maintained, all resources cleaned up when done.

Error handling: Errors stop execution immediately, can retry entire workflow, no state to recover (everything in memory), fast failure and recovery.

Synchronous Workflow Pattern Use Cases

Build synchronous workflows for:

  • REST/SOAP API Endpoints - Return data immediately to client requests
  • Data Validation Logic - Validate input and return errors instantly
  • Format Conversions - Transform CSV to JSON, XML to JSON in real-time
  • Database CRUD Operations - Query, insert, update with immediate response
  • Calculation Logic - Perform computations and return results
  • Real-time Integrations - Call external APIs and return responses

Troubleshooting Synchronous Workflow Issues

Problem Detection Cause Fix Notes
Workflow timeout Execution exceeds time limit Long database query or external API delay Optimize queries, consider async pattern If >30 seconds, use async
Unexpected long execution Workflow takes minutes instead of seconds Processing large datasets synchronously Split into batches or convert to async Async better for >30 sec

Asynchronous Workflow Pattern

Workflows that pause their execution to wait for external events before continuing. Think of them like a manufacturing assembly line that stops at a quality control checkpoint—the product sits on the conveyor belt while a technician performs tests in another department, and the line only resumes moving that specific product forward once the test results come back approved. You follow this pattern when your workflow includes nodes that need to wait, such as the Wait Event Node and Wait Time Node.

Getting Started with Asynchronous Workflows

What an asynchronous workflow looks like:

1
2
3
4
5
[Invoke Function Node: Send Email] → [Wait Event Node] → [Map Node: Process Reply] → [Continue]
                           ↓ (Martini pauses here)
                           ↓ (saves state, releases resources)
                           ↓ (waits for email response event)
                           ↑ (resumes when event arrives)

You create this pattern when your workflow uses:

Enterprise Scenario: Customer Lead Qualification Process

A CRM system needs to send lead qualification emails to prospects and wait for their response before proceeding:

1
2
[API Request (Start Trigger Node): New Lead] → [Map Node: Format Lead Data] → [Invoke Function Node: Send Qualification Email to Prospect] 
→ [Wait Event Node: Prospect Reply] → [Map Node: Process Response] → [Database Node: Update Lead Status]
  • Marketing submits new lead information (Sends an API Request which triggers the workflow via the Start Trigger Node)
  • System formats lead data and creates qualification questionnaire (Map Node)
  • Sends email to prospect with qualification questions (Script Node)
  • Workflow pauses here - could wait hours or days for prospect response (Wait Event Node)
  • When prospect replies, workflow resumes and processes their qualification responses (Map Node)
  • Updates lead record with qualification status and next steps (Database Node)

This asynchronous pattern handles the reality that prospects need time to respond to qualification emails, which could take anywhere from hours to weeks.

Asynchronous Workflow Pattern Key Characteristics

Characteristic Description
Execution Pauses at wait nodes, resumes on events or after configured duration
Duration Minutes to days (spans time)
Resources Released during waits, restored when resuming
State Automatically persisted by Martini during pauses
Best For Email workflows, scheduled jobs, approvals, long processes

How Asynchronous Workflows Execute in Martini

When you start an asynchronous workflow:

  1. Martini receives the trigger (Start Trigger Node, Email Trigger Node, Scheduler Node, Webhook Node, or other trigger types)
  2. Executes nodes until reaching a wait node
  3. Automatically saves workflow state to persistence
  4. Releases execution resources (thread, memory)
  5. Monitors for the trigger event (email, time, webhook)
  6. Restores saved state when event occurs
  7. Continues execution from pause point

Resource behavior: Thread released during wait, state persisted to storage, resources freed while waiting, efficiently handles hours/days of waiting.

Error handling: Can resume from last saved state, no need to restart entire workflow, state recovery mechanisms, handles system restarts gracefully.

Why Asynchronous Workflows Are More Resource-Efficient

The key advantage of asynchronous workflows is resource efficiency during waiting periods. Here's what happens under the covers:

Thread Behavior Comparison

SYNCHRONOUS PATTERN (Thread Blocks) 

1
2
3
4
5
6
7
8
Thread: Send email request
Thread: Check inbox... nothing yet (THREAD BUSY)
Thread: Check inbox... nothing yet (THREAD BUSY)  
Thread: Check inbox... nothing yet (THREAD BUSY)
Thread: Finally found response! (THREAD BUSY entire time)
Thread: Continue with next step

(Thread was held captive for entire waiting period)

ASYNCHRONOUS PATTERN (Thread Released) 

1
2
3
4
5
6
7
8
Thread: Send email request
Thread: Tell background system "notify me when email arrives"
Thread: RELEASED to help other workflows
Background System: (monitors email continuously)
Background System: "Email received! Calling thread back..."
Thread: Returns and continues with next step

(Thread was free to do other work while waiting)

Resource Impact Analysis

Synchronous approach (resource inefficient):

  • Thread held captive for entire waiting period
  • Memory allocated and held throughout
  • System resources tied up doing repetitive checking
  • If 100 workflows wait for emails = 100 busy threads doing nothing productive

Asynchronous approach (resource efficient):

  • Thread immediately released during wait
  • Memory freed while waiting, state saved to storage
  • One background system monitors all email events
  • If 100 workflows wait for emails = 1 background monitor + 100 free threads

The Wait Node Advantage

This is why adding wait nodes is important:

Wait Duration Synchronous Impact Asynchronous Benefit
30 seconds Thread busy for 30s Thread free for 29.9s
5 minutes Thread busy for 5min Thread free for 4min 59s
2 hours Thread busy for 2hrs Thread free for 1hr 59min
3 days Thread busy for 3 days! Thread free for 2 days 23hrs

Real-world impact: - Email approval workflow waiting 2 days for response: Synchronous holds expensive resources for 48 hours, Asynchronous releases them immediately - Monthly report waiting 30 days until next run: Synchronous would hold resources for a month, Asynchronous costs almost nothing while waiting - Batch processing with 1000 items needing external confirmations: Synchronous needs 1000 threads, Asynchronous needs background monitoring + threads available for other tasks

How Wait Nodes Create Resource Efficiency

When you use wait nodes in your workflow (Wait Event Node, Wait Time Node), Martini automatically:

  1. Pauses execution at the wait node - "This workflow needs to wait for something"
  2. Releases thread and memory resources - "No point holding resources while waiting"
  3. Saves workflow state to storage - "I need to remember where we left off"
  4. Resumes when the wait condition is met - "Time to continue from where we paused"

You don't configure this behavior - it's built into how wait nodes work.

Think of it like: A restaurant server (thread) who doesn't stand by your table while your food cooks - they help other customers and return when your order is ready. This allows the restaurant to serve many more customers with the same number of servers.

This is why asynchronous workflows aren't "slower" - they're smarter about resource management during inevitable waiting periods.

Key Martini Nodes That Create Asynchronous Patterns

Node Type What It Does Workflow Behavior
Wait Event Node Waits for a specific event to occur Pauses until event occurs, then continues with event data
Wait Time Node Waits until specific date, time, or recurring schedule Pauses until time condition met, then continues execution

Asynchronous Workflow Pattern Use Cases

Build asynchronous workflows for:

  • Email-Driven Processes - Send email, wait for reply, process response
  • Scheduled Automation - Run tasks daily, weekly, monthly at specific times
  • Approval Workflows - Route for approval, wait for decision, proceed accordingly
  • Long-Running Business Processes - Multi-day workflows with wait points
  • Event-Driven Integrations - Wait for external system callbacks
  • Webhook-Based Integrations - Send request, wait for confirmation callback

Real-world examples:

Example 1: Purchase Order Approval

1
2
3
[Script Node: Submit PO] → [Map Node: Check amount] → If >$10k: [Script Node: Send approval email] →
[Wait Event Node: Wait for approval] → If approved: [Script Node: Process order] → [Script Node: Notify requester]
(can span hours or days)

Example 2: Monthly Billing

1
2
3
[Wait Time Node: First day of month] → [Database Node: Find due subscriptions] →
[Script Node: Process payments] → [Script Node: Send invoices] → [Script Node: Log results]
(waits up to 30 days between executions)

Example 3: Support Ticket System

1
2
3
[Wait Event Node: Support request] → [Map Node: Create ticket] → [Script Node: Assign to team] →
[Wait Event Node: Resolution received] → [Script Node: Close ticket] → [Script Node: Send confirmation]
(spans hours to days)

Understanding Synchronous vs Asynchronous in Programming Context

In general programming, "synchronous" means operations that block and wait for completion, while "asynchronous" means operations that don't block and can continue or be resumed later. Martini's workflow terminology aligns perfectly with these concepts:

Synchronous workflows (like synchronous function calls):

  • Execute all operations in sequence, blocking until each completes
  • Thread continues until end of execution, holding all resources throughout
  • No resources released until an output is reached
  • Not ideal for logic dependent on processes that could take more than a few seconds - causes poor resource management and potential timeouts

Asynchronous workflows (like async/await patterns or event-driven programming):

  • Can suspend execution and resume later when external events occur
  • Use wait nodes that allow resources to be released while background processes occur
  • Thread freed to work on other tasks while waiting for independent processes
  • Ideal when a process needed for your logic can take a long time but can execute independently - excellent resource efficiency

Martini's Advantage: Rather than requiring explicit async/await syntax, Martini makes it easier to build asynchronous workflows by providing dedicated wait nodes (Wait Event Node, Wait Time Node) that automatically handle the resource management and thread coordination for you.

Troubleshooting Asynchronous Workflow Issues

Problem Detection Cause Fix Notes
Workflow never resumes Stuck in waiting state Event not received or listener misconfigured Verify event source, check listener config Check workflow monitoring
Lost state data Workflow resumes with missing information State persistence failure Contact support to verify storage Rare occurrence
Duplicate execution Same workflow runs multiple times Duplicate events or retry issues Implement idempotency checks Use unique execution IDs
Workflow "stuck" but working Shows waiting status for long time Normal - waiting for scheduled time or event Check what event it's waiting for Not an error

Understanding Synchronous vs Asynchronous in Programming Context

In general programming, "synchronous" means operations that block and wait for completion, while "asynchronous" means operations that don't block and can continue or be resumed later. Martini's workflow terminology aligns perfectly with these concepts:

Synchronous workflows (like synchronous function calls):

  • Execute all operations in sequence, blocking until each completes
  • Thread continues until end of execution, holding all resources throughout
  • No resources released until an output is reached
  • Not ideal for logic dependent on processes that could take more than a few seconds - causes poor resource management and potential timeouts

Asynchronous workflows (like async/await patterns or event-driven programming):

  • Can suspend execution and resume later when external events occur
  • Use wait nodes that allow resources to be released while background processes occur
  • Thread freed to work on other tasks while waiting for independent processes
  • Ideal when a process needed for your logic can take a long time but can execute independently - excellent resource efficiency

Martini's Advantage: Rather than requiring explicit async/await syntax, Martini makes it easier to build asynchronous workflows by providing dedicated wait nodes (Wait Event Node, Wait Time Node) that automatically handle the resource management and thread coordination for you.

What Makes Workflows Synchronous or Asynchronous

Understanding what creates each pattern based on the nodes you use in your workflow.

What Makes a Workflow Asynchronous

Your workflow becomes asynchronous when you include wait nodes that pause execution:

Wait nodes that create asynchronous behavior:

When to use wait nodes:

  • Need to wait for email responses from users
  • Schedule tasks to run at specific times (daily, weekly, monthly)
  • Wait for external system callbacks or confirmations
  • Handle approval processes that take time
  • Coordinate with long-running external processes

Example scenarios requiring wait nodes: 

1
2
3
4
Send email → [Wait Event Node] → Process reply
Submit request → [Wait Event Node] → Handle approval response  
Process data → [Wait Time Node: Next Monday 9am] → Generate weekly report
Send webhook → [Webhook Node] → Receive confirmation

What Makes a Workflow Synchronous

Your workflow remains synchronous when you use standard processing nodes that execute immediately:

Standard nodes that create synchronous behavior:

When to use standard nodes:

  • Build REST API endpoints that return immediate responses
  • Validate input data and return errors instantly
  • Transform data between formats (JSON, XML, CSV)
  • Perform calculations and return results
  • Query databases for immediate responses

Example scenarios using standard nodes: 

1
2
3
Receive API Request (Start Trigger Node) → [Map Node] → [Database Node Query] → [Map Node] → Return response
Upload file → [Script Node: Validate] → [Map Node: Transform] → [Database Node: Save] → Confirm
User input → [Map Node: Format] → [Invoke Service Node: Process] → [Map Node: Results] → Display

Pattern Recognition Guide

Look at your workflow to identify the pattern:

1
2
3
4
Contains any wait nodes?
├─ [Wait Event Node] ────────────────► ASYNCHRONOUS
├─ [Wait Time Node] ─────────────────► ASYNCHRONOUS  
└─ Only standard processing nodes ──► SYNCHRONOUS

Visual indicators on your workflow canvas:

  • Asynchronous: Workflow has pause points where execution stops and waits
  • Synchronous: Workflow flows continuously from start to finish without pauses

Use Case Guidelines

Your Requirement Use These Nodes Result Pattern
API that updates customer data Start Trigger Node → Map Node → Database Node → Map Node Synchronous
Send qualification email, wait for response Start Trigger Node → Script Node → Wait Event Node → Map Node Asynchronous
Daily report generation Wait Time Node → Database Node → Script Node → Email Asynchronous
Data validation service Start Trigger Node → Map Node → Validator → Map Node Synchronous
Approval workflow Script Node → Wait Event Node → Map Node → Database Node Asynchronous
File format converter Start Trigger Node → Map Node → Transform → Map Node Synchronous

How Martini Handles Your Workflow Pattern

Martini handles your workflow behavior automatically based on the nodes you use:

  • Contains Wait Event Node, Wait Time Node, or similar nodes → Martini pauses execution at these nodes, saves state, and resumes when events occur
  • Contains only processing nodes → Martini runs the workflow continuously from start to finish
  • You don't configure this → The behavior emerges naturally from your node choices

Visual Pattern Recognition Guide

Look at your workflow designer:

1
2
3
4
5
6
Do I have any of these nodes?
├─ Email Trigger Node ─────────────────► Pattern: ASYNCHRONOUS
├─ Scheduler Trigger Node ───────────────► Pattern: ASYNCHRONOUS
├─ Webhook Node ──────────────► Pattern: ASYNCHRONOUS
├─ Human Task ────────────────────► Pattern: ASYNCHRONOUS
└─ None of these ─────────────────► Pattern: SYNCHRONOUS

What Happens Behind the Scenes

For synchronous workflows, Martini:

  • Keeps everything in memory during execution
  • Maintains active execution thread
  • Returns response when complete
  • Requires no state persistence

For asynchronous workflows, Martini:

  • Saves workflow state when reaching wait node
  • Releases execution resources during wait
  • Monitors for trigger events
  • Restores state and continues when event arrives
  • Manages all persistence automatically

Common Questions About Workflow Patterns

Frequently asked questions about synchronous and asynchronous patterns.

Pattern Behavior Questions

Q: What happens if Martini restarts while my async workflow is waiting? A: Martini automatically restores the workflow state and continues waiting. No data is lost because state is persisted before pausing.

Q: My asynchronous workflow seems "stuck"—is this normal? A: Yes, this is normal behavior! Asynchronous workflows pause while waiting for events or the configured duration.

Q: How long can an asynchronous workflow wait? A: As long as needed—hours, days, or weeks. You can optionally set timeout limits as part of the Wait Node's configuration. See Wait Time Node or Wait Event Node for timeout configuration options.

Q: I'm getting timeout errors with my synchronous workflow. What should I do? A: If your synchronous workflow consistently takes longer than 30 seconds, consider converting it to asynchronous. See our troubleshooting guide for step-by-step conversion tips.

Next Steps

After completing this guide:

  1. Start building workflows: Learn how to create your first workflow in Martini Designer
  2. Master the visual editor: Explore the Workflow Designer to understand how to add, connect, and configure nodes
  3. Discover all available nodes: Browse the complete Workflow Nodes reference to see what building blocks are available
  4. Build asynchronous workflows: Deep dive into Wait Time Node and Wait Event Node for time-based and event-driven workflows
  5. Join the community: Get help and share examples at Martini Community

Recommended learning path:

  1. Create your first synchronous workflow (30 minutes)
  2. Practice with the Workflow Designer interface (30 minutes)
  3. Experiment with wait nodes for asynchronous patterns (1 hour)
  4. Build real enterprise scenarios (ongoing)

Helpful Resources