Rate limits¶
Sliding-window rate limits προστατεύουν τους upstream providers και μοιράζουν δίκαια την χωρητικότητα μεταξύ clients.
Πιο σημαντικό από τα νούμερα: στήστε το integration σας ώστε bursts, retries και background jobs να μη συγκρούονται.
Current limits¶
| Tier | Beta | Production |
|---|---|---|
Per Keycloak client (azp) |
2,000 req/min | 10,000 req/min |
| Per provider (route prefix) | 500 req/min | 2,000 req/min |
| Global (whole API) | 5,000 req/min | 20,000 req/min |
Κάθε request μετράει και στα τρία tiers. Αν ξεπεράσετε οποιοδήποτε →
429 Too Many Requests.
429 response¶
HTTP/1.1 429 Too Many Requests
Retry-After: 30
Content-Type: application/problem+json
{
"type": "https://tools.ietf.org/html/rfc6585#section-4",
"title": "Too Many Requests",
"status": 429,
"detail": "Rate limit exceeded for client 'agentins'.",
"retry-after-seconds": 30
}
Όταν υπάρχει Retry-After, σεβαστείτε το πάντα.
Retry strategy¶
Σε 429 και προσωρινά 5xx → exponential backoff με jitter, όχι immediate retry.
Με 1s base delay, cap στα 60s:
| Attempt | Delay |
|---|---|
| 1 | 1s + jitter |
| 2 | 2s + jitter |
| 3 | 4s + jitter |
| 4 | 8s + jitter |
| 5 | 16s + jitter |
| 6+ | capped at 60s |
Αν τα retries συνεχίσουν να αποτυγχάνουν, σταματήστε και περάστε το στο monitoring/on-call flow σας.
C# example¶
async Task<HttpResponseMessage> SendWithRetryAsync(HttpRequestMessage req)
{
var maxAttempts = 6;
for (int attempt = 0; attempt < maxAttempts; attempt++)
{
var resp = await _http.SendAsync(req);
if (resp.StatusCode != HttpStatusCode.TooManyRequests &&
resp.StatusCode != HttpStatusCode.ServiceUnavailable)
return resp;
var retryAfter = resp.Headers.RetryAfter?.Delta
?? TimeSpan.FromSeconds(Math.Pow(2, attempt));
var jitter = TimeSpan.FromMilliseconds(Random.Shared.Next(0, 1000));
await Task.Delay(retryAfter + jitter);
}
throw new InvalidOperationException("Rate limit retries exhausted");
}
Best practices¶
Αυτά δουλεύουν
- Cache lookup data (brands, countries, static parameters)
- Queue ή stagger background jobs αντί να ξεκινούν όλα μαζί
- Monitor το
429rate σας σε production - Batching όπου το επιτρέπει η ροή
Αυτά συνήθως σκάνε
- Tight retry loops
- Polling κάθε λίγα 100ms
- Direct frontend traffic → API calls χωρίς buffering
Χρειάζεστε higher limits;¶
Στείλτε στο Support:
- Το
client_idσας - Expected peak throughput
- Traffic pattern
- Σύντομο business context για το workload