Workflow rate limits and throughput

A workflow's useful throughput is the rate at which it completes actions, not the rate at which it starts runs. Plan around the slowest constrained step — an API limit, worker capacity, a queue or the destination's ability to accept changes. Fast event intake can still leave a growing backlog.

Map events to completed actions

For a representative event, list the trigger, queue, outbound calls, retries and final destination action. Mark where work waits. Keep units distinct: events per minute, requests per minute, records per request and completed records per minute cannot be compared directly.

Estimate normal and peak arrivals from your event history. Measure sustainable completions under a load that is safe for the destination. If arrivals stay above completions, backlog grows; when arrivals fall, spare completion capacity determines how quickly it clears.

Find the constraint

Check the provider's current documented limits for the credential and operation you use. Limits and response signals can vary by endpoint and authentication method.

More workers help only while shared limits and downstream capacity have room. Once an API is the constraint, extra workers can create more throttled calls. Coordinate pacing across workers and include other workflows that share the same allowance.

Batching can reduce calls per record where an operation supports it. Check its entry and payload limits, response semantics and the time records wait for a batch to fill. Batching can improve publisher efficiency and increase throughput, but it adds latency for individual messages. A successful batch response may still require per-record reconciliation, depending on the operation.

Top 3 Factors Affecting Workflow Throughput in Australia

Set a capacity baseline

Turn provider limits into an initial request budget for the actual authentication method and operation. GitHub documents a primary limit of 60 REST API requests per hour for unauthenticated public-data requests and 5,000 per hour for authenticated users; some endpoints, including search, have more restrictive limits.

A GitHub App owned by a GitHub Enterprise Cloud organisation can have a 15,000-request hourly limit. That higher-limit app's requests can also reduce the remaining budget for lower-limit authentication methods: GitHub gives the example of 10,000 requests exhausting a personal access token's 5,000-request budget. Account for shared credentials rather than treating each workflow as an independent allowance.

API Rate Limits Across Major Cloud Providers (Australia)

Balance batch efficiency against delay

Google Cloud Pub/Sub enables batching by default in its client libraries. Combining messages into one publish request can improve publisher efficiency and throughput, but messages may wait while a batch forms; choose batching settings with both the destination's request capacity and the acceptable completion delay in view.

Before relying on message retention to absorb a delay, confirm messages will be retained for the intended consumers. Google Cloud says to attach a subscription before publishing or enable topic message retention; without either, messages published before a subscriber is attached are not retained for later delivery.

Give bursts a safe place to wait

A queue can separate intake from outbound processing. Check its retention, delivery behaviour and applicable limits, then compare backlog age with the business deadline. Amazon SQS has finite, configurable message retention and publishes an ApproximateAgeOfOldestMessage metric. Those metrics do not confirm that a destination action finished.

Control producer intake if a publishing client can accumulate more outstanding work than it can hold. Decide how to handle events that would become stale before processing.

Set queue headroom and a recovery limit

Amazon SQS retains messages for four days by default, and its retention period can be configured up to 14 days. Compare that window with the maximum delay the workflow can tolerate, and configure the visibility timeout — the period a received message is hidden from other consumers — so queue behaviour fits the processing time.

Amazon SQS reports ApproximateAgeOfOldestMessage in seconds, but distributed-queue metric values can be approximate. Use these as operational signals alongside confirmed destination completions, not as proof that every queued message has completed.

For an Amazon SQS FIFO queue, ApproximateNumberOfGroupsWithInflightMessages indicates how many message groups have messages being processed. AWS notes that high values usually indicate strong concurrency; if the queue has a large backlog while this value stays low, scaling consumers or increasing the number of active message groups may improve throughput.

Amazon SQS Queue Configuration Defaults (Australia)

Reserve capacity for retry traffic

Exponential backoff retries operations with increasing wait times across a specified number of attempts. Retries can occupy network bandwidth and slow responses, while longer backoff waits can extend the time before a caller receives a result; include both effects when setting the retry attempt and time budget.

Count retries as demand

Every retry uses capacity. On throttling, follow the provider's response guidance and slow affected traffic. Treat a timed-out write as an unknown outcome until the destination can be checked or a supported idempotency mechanism makes another attempt safe.

Monitor arrivals, confirmed completions, throttled attempts, retry volume, queue depth and age, and trigger-to-completion delay. Set a recovery target from the business deadline, then adjust pacing, concurrency or batch size against observed completions. Recheck the plan when the event mix or destination changes.