PATTERN Cited by 1 source

Adaptive rate-limited scheduling

Definition

Apply a dynamically recomputed rate limit to the scheduler that enqueues work, so that work is uniformly distributed over the scanning/processing interval regardless of changes to the total workload size. The rate is periodically recalculated (e.g., every 30 minutes) based on current population counts and target frequencies.

Mechanism

rate = Σ (count_per_tier / scan_interval_per_tier) × buffer_factor

1. Query the database for current counts per tier/class.
2. Divide each by its target scan interval to get the required throughput per tier.
3. Sum across tiers and multiply by a buffer factor (to absorb downtime recovery).
4. Set this as the token-bucket or leaky-bucket rate for the scheduler.
5. Repeat every N minutes asynchronously.

Trade-offs

Pro	Con
Automatically adapts to population growth	Assumes relatively uniform per-item cost
Prevents spikes when frequency changes	30-min recalculation lag can under-shoot during rapid growth
Simple to implement (single rate limiter)	Buffer factor must be tuned empirically
Prevents Kafka/queue overflow	Does not address individual-item cost variance

When to use

• A scheduler must enqueue periodic work for a population that grows over time.
• Fixed rate limits would either over-provision (waste) or under-provision (miss SLAs) as population changes.
• The downstream system has a known sustainable throughput that should not be exceeded.

Seen in

• sources/2026-06-12-cloudflare-scaling-security-insights — Cloudflare's scan scheduler recomputes its rate limit every 30 minutes from account/zone counts per tier (free, pro, business, enterprise) and their respective scanning intervals. A rateLimitBufferFactor provides headroom for downtime recovery.