Throttle mode

Allow events to be emitted at a consistent, limited rate. Throttle mode helps you to respect rate limits when interacting with 3rd party APIs. This logic is applied to all events regardless of which story run they are from.

Features​ 

  • Emit events at a limited rate and at consistent intervals.

  • This logic is applied to all events across all story runs - separate story runs are not given separate capacity.

  • The newly emitted event will also contain a capacity_per_minute key which shows how many runs of the action were allowed each minute when the event was emitted.

  • Throttled events are placed in a queue until they are emitted. Events will be dropped instead of being added to the queue if there are 20,000 or more events in the queue already.

Note: The 20,000 throttled events queue is tenant-wide, not per Throttle action. All Throttle actions share this limit, and throttled events from any action count toward the total.

Configuration Options​ 

  • interval: the duration of time over which the throttle action schedules its runs. Allowed values are minute (default), hour, and day.

  • runs_per_interval: The maximum number of times that the action can run in each interval. Runs will be evenly spaced out across each interval.

  • events_per_run: The number of events emitted in each run (1-10).

  • throttle_key (optional): Group events by interpolated values (e.g., user_ID) instead of processing them as one queue. When configured, events with the same key value will be throttled together. If left blank, all events will be throttled together. Each unique throttle key is allowed to process up to events_per_run events per interval.

For example, if there were a Throttle action configured with 20 runs per minute and five events per run:

Interval: minute, Runs per interval: 20, Events per run: 5

Then, if it received at least 100 events per minute, we would expect it to emit five events every three seconds.

If the Throttle action received more than 100 events per minute on average, it would continue to steadily put out five events every three seconds in the order they were received, but a backlog would begin to amass. If it started receiving less than 100 events per minute, it would eventually consume that backlog and start putting out less than five events every three seconds, and possible none at all for some runs.

Was this helpful?