Skip to content

Rate limits, throttling, and graceful queueing

ریٹ لمٹ، تھروٹلنگ، اور پرسکون قطار

33 min read

Three ways to see it

  1. A rate limit is the maximum number of requests the vendor will accept from your account per minute, per hour, or per day. Anthropic and OpenAI publish these on dedicated pages and tier them by spend: a free account might get 5 requests per minute, a paid tier 50, a higher tier 500. They are not arbitrary; they exist because the vendor's GPUs are finite and fairness across customers requires a cap. The cap is also a soft promise: you can usually raise it by writing to support and showing volume forecasts.

  2. Three patterns to absorb traffic bursts. First, exponential backoff: when you hit a 429 error, wait 1 second, retry; if it fails, wait 2 seconds; then 4, then 8, capped at 60. Most SDKs have this built in but disabled by default. Turn it on. Second, request queueing: instead of firing every request directly at the API, push them into an internal queue and let a worker drain the queue at the rate the API tolerates. This smooths the Monday-morning spike into a Monday-morning hour. Third, request prioritisation: if the queue is full, decide which requests are urgent (a citizen waiting on the phone) and which can wait (an overnight batch). Drop or delay the latter when capacity is tight.

  3. Two specific Pakistani patterns are worth designing for. Pattern one is the 9-am-Monday-spike, where every officer in every district opens the tool at the start of the work week. The fix is staggered scheduling: a 30-minute warm-up where the tool offers cached responses for common questions, with full model access opening progressively from 9 to 10 am as the queue clears. Pattern two is the end-of-quarter-burst, where compliance, finance, and audit teams all generate reports the same Friday. The fix is calendar-aware capacity planning: ask the vendor for a temporary rate-limit bump for the last week of each quarter, then drop back. Vendors say yes to predictable, well-explained requests.

Quick check

Quick check: what makes modern AI different from a rule-based program?

The why-tree

Why-tree level one: why do vendors publish rate limits as ranges per tier? Because predictability lets you architect. Hidden limits force you to discover them through outages. Public limits let you build the queue, configure the backoff, and write the SLA before launch. Use that gift.

Try this with Claude

AI-edge prompt: 'I am deploying an AI assistant to 1000 FBR officers in 75 cities. Monday-morning peak is 800 concurrent users for 30 minutes. Design a rate-limiting and queueing architecture using exponential backoff, a Redis-backed queue, and priority lanes. Give me the worker count, the queue depth alert threshold, and the user-facing wait-time copy in English and Urdu.' Compare what the model proposes to your own back-of-envelope.

Sources

Sources and further reading. Anthropic, Rate limits (docs.anthropic.com/en/api/rate-limits). OpenAI, Rate limits (platform.openai.com/docs/guides/rate-limits). AWS, Exponential backoff and jitter (aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter). Redis-backed task queue patterns (Celery, BullMQ, Sidekiq documentation). Google SRE Workbook chapters on overload and graceful degradation (sre.google). NIST AI RMF MEASURE function for capacity planning.