Spike Limiter Implementation

Use the spike limiter guidance to identify request spikes, respond to HTTP 429 errors, and keep API traffic predictable.

Overview

Signal APIs use a dynamic spike limiter to protect against sudden, uncharacteristic traffic surges. Use it alongside the concurrency controls and gradual request ramp-up described in the rate limit best practices.

How the spike limiter works

• Dynamic Limits: The system calculates a unique requests-per-minute (RPM) limit for your organization based on your own recent usage patterns. It looks at your 60-minute rolling average traffic and also considers your traffic's variability to distinguish between normal fluctuations and genuine spikes.
• Real-Time Enforcement: When your request rate exceeds this dynamic limit, the API will respond with an HTTP 429 (Too Many Requests) error. The response will include a Retry-After header indicating when you can safely retry.
• Rolling Window: The spike limiter uses a rolling 60-minute window to determine your average and variability, recalculating limits every minute.

Respond to HTTP 429 errors

1. Pause and retry: Follow the Retry-After header if present, or introduce a delay before retrying
2. Review your workflow: Follow the Rate Limit Best Practices, including appropriate concurrency and gradual request ramp-up.
3. Monitor: If you continue to experience throttling, review your traffic patterns to identify any unexpected spikes or irregularities, and adjust accordingly

📘

Rate Limit Best Practices

Summary

• Adhere to concurrency and ramp-up best practices
• Monitor your API usage and system performance
• The spike limiter is designed to protect all customers and ensure fair access
• If you have questions about optimizing your workflow, contact support for guidance