Dispatcher and Performer

This page explains the purpose of the Dispatcher and the Performer within Curator's queue system. The goal is to help users, automation analysts, operations leads, and developers understand when to use each role, how they work together, and what to watch out for when designing a queue-based automation.

Dispatcher and Performer form the queues' producer and consumer model. The Dispatcher creates work items. The Performer processes those items.

Overview

In a traditional automation, a single robot can read a spreadsheet and process all rows from start to finish. This model works for simple flows, but becomes limited when volume grows, when multiple machines need to work together, or when the operation needs to track status per item.

With queues, the process is divided into two responsibilities:

Source system -> Dispatcher -> Queue in Curator -> Performer -> Target system

In this flow:

• The source system contains the data that needs to be processed.
• The Dispatcher transforms this data into queue items.
• The queue organizes items with status, priority, reference, history, and auditing.
• The Performer takes the available items, executes the business rule, and records the result.
• The target system receives the final action, such as registration, lookup, reconciliation, issuance, or update.

Separating Dispatcher and Performer helps scale processing, reduce duplication risk, track failures more clearly, and reprocess only the necessary items.

What is the Dispatcher

The Dispatcher is the automation responsible for feeding the queue. It collects data from a source, validates what needs to be sent, and creates queue items so other robots can process them later.

Common data sources:

• Spreadsheets with input rows.
• External system APIs.
• Databases.
• Exported reports.
• Files in a folder.
• Lists generated by another business process.

What the Dispatcher does

• Reads the data source.
• Filters records that should not be processed.
• Builds the business reference for each item.
• Sets priority, deadline, or postponement when needed.
• Creates the items in the queue.
• Avoids duplication when the queue uses unique references.
• Records a summary of what was sent.

Example: in an order process, the Dispatcher can query pending orders in the source system and create a queue item for each order that needs to be integrated.

What the Dispatcher does not do

The Dispatcher should not execute all the business work of each item. It should not, for example, open each order, fill in the target system, confirm the processing, and generate the final protocol. That responsibility belongs to the Performer.

This separation prevents a failure in an individual case from blocking the entire input load. The Dispatcher only prepares the queue; the Performer executes the work item by item.

When the Dispatcher finishes

The Dispatcher usually finishes when it completes reading the source and creates the corresponding items in the queue. It does not need to run continuously. In recurring operations, it is common to schedule the Dispatcher to run at defined times, for example:

• Every 15 minutes to fetch new orders.
• Once a day to load the contract base.
• At the start of the workday to prepare the service queue.
• After an external report becomes available.

What is the Performer

The Performer is the automation responsible for consuming queue items. It fetches the next available item, executes the business rule, and tells Curator whether the item finished with success or failure.

What the Performer does

• Fetches the next available item in the queue.
• Reserves the item to prevent simultaneous processing by another robot.
• Reads the item's input data.
• Executes the business rule.
• Records output data on success.
• Records the failure reason when something prevents processing.
• Differentiates business failures from technical failures.
• Moves on to the next item until the queue is empty.

Example: in an order process, the Performer can take an order from the queue, open the target system, register the integration, save the generated protocol, and mark the item as success.

Processing cycle

Fetch next item -> Process -> Record result -> Fetch next item

When there are no more items available, the Performer terminates normally. To keep processing continuous, the operation can run the Performer again via scheduling, an execution queue, or another mechanism defined by the team.

Multiple Performers on the same queue

A queue can be consumed by multiple Performers at the same time. This allows distributing the volume across machines, robot users, or parallel instances of the same automation.

Orders Queue -> Performer 1
             -> Performer 2
             -> Performer 3

Curator coordinates item delivery to prevent two Performers from processing the same item simultaneously. Even so, the automation must be idempotent: if an item is repeated due to retry or an operational action, it must not create duplication in the target system.

How they work together

Dispatcher and Performer communicate through the queue. They do not need to run on the same machine, at the same time, or in the same project. The meeting point is the queue item.

A common design is:

1 Dispatcher -> 1 queue -> multiple Performers

The Dispatcher defines which items enter. The Performer defines how each item is executed. The queue keeps the state between these two stages.

Data contract

For the model to work well, Dispatcher and Performer need to agree on the item's data format. This agreement is called the data contract.

The Dispatcher must create items with fields the Performer knows how to interpret. The Performer must handle absence, invalid format, and unexpected values clearly, recording a business failure when the data does not allow continuing.

Item example:

{
  "reference": "PED-88421",
  "priority": "normal",
  "specific_data": {
    "cliente_id": "C-1024",
    "numero_pedido": "88421",
    "valor_total": 1520.75,
    "canal": "portal"
  }
}

In this example:

• reference is the business identifier used to locate and audit the item.
• priority indicates the relative processing order.
• specific_data contains the data the automation needs to execute the case.

When to use Dispatcher and Performer

Use Dispatcher and Performer when the process has multiple independent units of work and needs per-item operational control. This model is recommended when you need:

Examples:

• A Dispatcher loads pending invoices and multiple Performers post the invoices in the tax system.
• A Dispatcher fetches approved customers and multiple Performers create registrations.
• A Dispatcher lists expiring contracts and multiple Performers run lookups or updates.

When to consider another model

Not every process needs to be split into Dispatcher and Performer.

Model	When to use
Base Model	The process is still small or experimental; local spreadsheet input is sufficient; there is no need for parallelism; the team is still validating the business rule.
Combined model (feeds and consumes in the same agent)	The source is simple; volume is low or medium; the operation does not need to separate responsibilities; the team wants fewer projects to maintain.
Separate Dispatcher and Performer	Volume may grow; more than one machine needs to process items; the data source differs from execution; the operation needs to control input and processing independently; individual failures must not block the entry of new items.

Creating in Curator

A recommended flow for creating this type of automation is:

1. Create the queue in Curator with a clear name and objective description.
2. Define whether the reference must be unique.
3. Configure retry, deadline, retention, and agent association when needed.
4. Create a Dispatcher project using Curator's wizard.
5. Configure the queue name used by the Dispatcher.
6. Implement or adjust the data source reading.
7. Create a Performer project using Curator's wizard.
8. Configure the same queue name in the Performer.
9. Implement the Performer's business rule.
10. Test with a few items before releasing the full load.

During testing, validate at least these scenarios:

• ☑️ Item processed successfully.
• ☑️ Item with a known business failure.
• ☑️ Item with a temporary technical failure.
• ☑️ Dispatcher running twice over the same input.
• ☑️ More than one Performer consuming the same queue, when there is parallelism.

Operational monitoring

On the queues screen, monitor:

This information helps decide whether to run more Performers, pause the Dispatcher, fix source data, retry items, or investigate a recurring failure.

Best practices

For the Dispatcher

• Use stable business references.
• Filter clearly invalid records before enqueueing.
• Do not send data the Performer does not use.
• Record how many items were read, skipped, and created.
• Prefer controlled scheduling over infinite loops.
• Avoid creating duplicate items when the same source can be read more than once.

For the Performer

• Separate business failures from technical failures.
• Record failure messages that help the operation act.
• Ensure idempotency before enabling retry.
• Save relevant output data, such as protocol or final status.
• Do not let one item's error stop the whole batch without recording the reason.
• Test with anonymized real data before going to production.

For the queue

• Use clear, stable names.
• Document the data contract.
• Configure retry only for technical failures.
• Monitor accumulation of new items.
• Periodically review failed items.
• Remove unnecessary sensitive data.

Common mistakes

Frequent mistakes in Dispatcher and Performer projects:

• ❌ Creating items without a clear business reference.
• ❌ Using different fields in the Dispatcher and the Performer.
• ❌ Putting all the work inside the Dispatcher.
• ❌ Treating every failure as technical and retrying cases that will never pass.
• ❌ Processing items without idempotency.
• ❌ Enqueueing sensitive data unnecessarily.
• ❌ Running many Dispatchers without duplication control.
• ❌ Increasing retries before investigating the failure cause.

Avoiding these mistakes makes the queue more predictable, reduces operational rework, and facilitates auditing.

Next steps

• Read Queue System to understand the general concepts of queues, statuses, priorities, and retry.
• Read Queue Items to define the data contract connecting Dispatcher and Performer.
• Read Operations and Best Practices to learn how to monitor queues, investigate failures, and keep the operation healthy.