gitlabEdit

โฑ๏ธSync vs Async

Docs-Dispatcher supports both synchronous and asynchronous execution modes. This guide explains the differences, when to use each mode, and best practices for handling responses.

Quick Comparison

Feature

Sync (?async=false)

Async (?async=true)

Response time

Waits for completion (seconds to minutes)

Immediate (< 5 seconds)

Returns

Full provider response

Dispatch ID only

Best for

Quick operations (< 2 min)

Long operations, batch jobs

Timeout

120 seconds

No timeout (queued)

Notifications

Response only

Webhook callback

Error handling

Immediate in response

Via webhook

Resource usage

Blocks connection

Non-blocking

Synchronous Mode (Default)

In synchronous mode, the API waits for the entire operation to complete before returning a response.

How It Works

Client Request โ†’ Dispatcher โ†’ Provider API โ†’ Response โ†’ Client
                  โ†“
              Wait for completion
              (blocks connection)

Request:

Execution flow:

  1. Client sends request

  2. Dispatcher validates request

  3. Dispatcher calls provider API

  4. Dispatcher waits for provider response

  5. Dispatcher returns full response to client

Example Request

Example Response (Immediate)

When to Use Sync Mode

Use synchronous mode when:

  1. User is waiting for result - User interface needs immediate feedback

  2. Quick operations - Expected completion time < 30 seconds

  3. Simple workflows - Single service dispatch without chaining

  4. Interactive testing - Development and debugging

  5. Simple error handling - Handle errors in same request/response

Sync Mode Advantages

  • Immediate results - Get response right away

  • Simpler code - No webhook handling needed

  • Easier debugging - Errors returned directly

  • No infrastructure - No webhook endpoint required

Sync Mode Disadvantages

  • Connection blocking - Client waits for completion

  • Timeout risk - 120-second limit may not be enough

  • Resource usage - Holds server resources during wait

  • No progress updates - All or nothing response

Asynchronous Mode

In asynchronous mode, the request is queued immediately and processed in the background.

How It Works

Request:

Execution flow:

  1. Client sends request

  2. Dispatcher validates request

  3. Dispatcher queues job

  4. Dispatcher returns dispatch ID immediately

  5. Background worker processes job

  6. Worker calls provider API

Example Request

Example Response (Immediate)

Example Webhook Payload (Later)

When processing completes, your webhook receives:

When to Use Async Mode

Use asynchronous mode when:

  1. Long operations - Expected completion > 30 seconds

  2. Batch processing - Processing many dispatches

  3. Non-critical timing - User doesn't need immediate result

  4. High volume - Many concurrent requests

  5. Background jobs - Cron jobs, scheduled tasks

  6. Complex workflows - Multi-service composition

Async Mode Advantages

  • No timeouts - No 120-second limit

  • Better resource usage - Non-blocking connections

  • Scalability - Handle high volumes

  • Progress tracking - Webhook events provide updates

  • Resilience - Automatic retries on failure

Async Mode Disadvantages

  • Complexity - Requires webhook endpoint

  • Infrastructure - Need to handle webhooks

  • Delayed results - Not suitable for interactive use

  • Debugging - Harder to trace execution

Webhook Implementation

For async mode, you must implement a webhook endpoint to receive completion notifications.

Webhook Endpoint Requirements

  1. HTTPS required - HTTP not supported for security

  2. Return 200 OK - Within 10 seconds

  3. Idempotency - Handle duplicate events gracefully

  4. Authentication - Verify webhook signature (optional but recommended)

Webhook Handler Example (Node.js)

Webhook Handler Example (PHP)

Webhook Handler Example (Java)

Polling vs Webhooks

For async operations, you can either use webhooks or poll for status.

Pros:

  • Real-time notifications

  • No polling overhead

  • Lower latency

  • More efficient

Cons:

  • Requires public endpoint

  • More complex setup

  • Need to handle retries

Polling (Alternative)

Response:

Polling example:

Pros:

  • No webhook endpoint needed

  • Simpler setup

  • Works behind firewalls

Cons:

  • Higher latency

  • More API calls

  • Less efficient

  • Can miss events

Timeout Considerations

Sync Mode Timeouts

Synchronous requests have a 120-second timeout:

What happens on timeout:

Operations likely to timeout (use async instead):

  • Large document generation (> 50 pages)

  • Multi-signer eSign workflows

  • International postal dispatch

  • Batch operations

Async Mode (No Timeout)

Asynchronous requests never timeout:

  • Queue immediately (< 5 seconds)

  • Process in background (unlimited time)

  • Webhook notification on completion

Best Practices

1. Choose Mode Based on Duration

2. Use Async for Batch Operations

3. Implement Webhook Retries

Dispatcher retries failed webhooks up to 3 times:

Handle retries idempotently:

4. Monitor Async Queue

Track async dispatch status:

5. Fallback Strategy

Combine sync with async fallback:

Error Handling

Sync Mode Errors

Errors returned immediately in response:

Async Mode Errors

Errors sent via webhook:

Summary

Choose Sync when:

  • User is waiting for result

  • Operation completes quickly (< 30s)

  • Simple error handling

  • Testing/debugging

Choose Async when:

  • Long-running operations (> 30s)

  • Batch processing

  • Background jobs

  • High volume/scalability

Key differences:

  • Sync: Immediate response, 120s timeout, blocks connection

  • Async: Queue immediately, no timeout, webhook notification

Understanding execution modes helps you build robust, scalable integrations with Docs-Dispatcher.

Last updated