Skip to main content

​
Overview

In this guide, we’ll take a look at how Alloy handles concurrency when running workflow executions. Understanding concurrency is important to having a solid grasp of our infrastructure.

​
How it Works

To understand how concurrency works at Alloy, let’s take two scenarios:
  • Scenario 1: You have a single workflow that listens for new records created in BigCommerce and proxies those events over to your API. Let’s assume this workflow receives 5,000 events in the first hour.
  • Scenario 2: You’ve set up two workflows, one that receives customer sign-up events and adds them to a list in klaviyo, and a second workflow that receives Clicked Email events from Klaviyo and proxies those events to your API.
Alloy handles concurrency by spreading out workflow executions at the Workflow level. In other words, a workflow execution, or execution for short, represents any given job associated with a workflow. In Scenario 1, the rate at which Alloy can process the event and send it to your API is largely dictated by the rate-limiting of your API. If BigCommerce sends the first 1,000 events to Alloy over the course of a minute, we wouldn’t want to immediately send those 1,000 events to your API if it has a 60 request-per-minute limit. Alloy instead adds those requests to a queue spread out over time to avoid having to handle rate-limit errors with retries. When the remaining 4,000 events are received over the course of an hour, they will be queued up to run after the last batch of events if there are still any outstanding. In Scenario 2, if Alloy receives a customer signup event and clicked email event simultaneously, both workflows will execute simultaneously. These two workflows function independent of one another, and events received by one will not impact the event scheduling of the other.

​
Wrapping Up

In this tutorial, we took at look at how Alloy handles concurrency across workflow executions.