Skip to main content

FIFO Queues

By default executions run concurrently, meaning multiple webhook invocations of the same flow are processed at the same time. This is great for performance - dozens of webhook requests can all be processed in parallel, but it can lead to out-of-order processing or rate limiting.

To mitigate this, you can opt to place a queue in front of your flow. When First In, First Out (FIFO) is enabled, requests are processed one at a time in the order they are received. If your flow is already processing a request when a new request arrives, the new request is placed in a queue until the flow is ready to process it.

This is helpful in a few situations:

  • If it's important that requests are processed in the order they are received (e.g., financial transactions).
  • If your integration is sensitive to the load it places on downstream systems (e.g., third-party rate limits).
  • If you expect to encounter execution rate limits in Prismatic.

This ensures that your integration can handle bursts of traffic without overwhelming your integrations or downstream third-party apps, and ensures that messages are processed in the order they are received.

Enabling FIFO on a flow​

To enable a FIFO queue on a flow, select the flow's trigger and open the Flow control tab. Toggle Enable FIFO on.

When enabled, this flow will process one at a time in the order they're received (FIFO). Subsequent events wait in a queue until the current execution completes.

Note: This feature is available for webhook-based app event triggers and generic webhook triggers. It is not available for management, app event polling, or scheduled triggers, nor for pre-process flows. Additionally, flows that have FIFO enabled must be asynchronous.

Message deduplication​

Many applications ensure "at least once" delivery of outbound webhook requests, which can result in duplicate events being processed. To prevent processing duplicate requests, you can implement message deduplication strategies in your FIFO-enabled flows.

To enable automatic deduplication of messages, specify a Deduplication ID in your trigger's Flow control configuration. For example, if a third-party sends a header called x-acme-webhook-id, you can use that value as the Deduplication ID. If two requests with the same x-acme-webhook-id header are received within a 10-minute window, the second request will be considered a duplicate and will be ignored.

Enabling FIFO queue in code-native integrations​

FIFO queues can be enabled in code-native integrations' flows by adding a queueConfig property to your flow. usesFifoQueue must be set to true to enable FIFO. You can optionally specify a dedupeIdField to prevent message duplication.

export const listItems = flow({
  name: "List Items",
  stableKey: "abc-123",
  description: "Fetch items from an API",
  queueConfig: {
    usesFifoQueue: true,
    dedupeIdField: "body.data.webhook-id",
  },
  onTrigger: () => {},
  onExecution: () => {},
});

The above example assumes that the body of the incoming webhook request contains a field called webhook-id that uniquely identifies the event. To reference a header (for example, one named x-acme-webhook-id), you can use the following syntax:

dedupeIdField: "headers.x-acme-webhook-id",

Flow concurrency management FAQ​

Where can I see my queued requests?​

Queued requests will appear alongside your other executions.

In the integration designer if you observe a queued execution's logs, you will see a message like Queuing Execution for Instance 'Salesforce'. Total Queued Executions: 4.

Make sure that you toggle Logs on. When the queued execution is processed, you will see a message like Resuming Queued Execution for Instance Salesforce'. Total Queued Executions: 3. Total Concurrent Executions: 15 in the logs. The 15 there represents all concurrent executions of all flows.

In an instance's Executions tab, queued executions will also appear alongside running executions.

Why can't FIFO be enabled for a synchronous flow?​

The goal of a synchronous flow is to process requests in real time, providing immediate feedback to the caller. Queueing the request and processing it later would defeat that purpose.

Can I configure the number of concurrent executions for a flow?​

Currently, the number of concurrent executions for a flow is fixed and cannot be configured. A maximum of one execution will run at a time.

What happens to my FIFO queue if my instance is paused?​

No new executions will queue, but any existing executions that were queued will resume after the instance is enabled again.

What happens to my FIFO queue if my instance is deleted?​

All queued executions will be permanently removed and cannot be recovered.

What happens if I enable flow retry with FIFO?​

If you enable flow retry, failed executions will be retried in the order they were received, preserving the FIFO semantics.

For example, if an execution fails and your flow is configured to retry up to 3 times, waiting 2 minutes between failures, the failed execution will be retried after 2 minutes, then again after 4 minutes, and finally after 6 minutes (assuming it continues to fail). During that time, no other executions will be processed from the queue.

If an execution ultimately fails after all retries, it will be marked as failed and the next execution in the queue will be processed.

How many executions can be queued?​

There is no current hard limit on the number of executions that can be queued, but keep in mind that excessive queuing will result in delayed processing of new requests.