Qu'est-ce que le rate limiting et le throttling d'API ?

Le rate limiting est un contrôle qui plafonne le nombre de requêtes d’un client par fenêtre ; le throttling ralentit l’excédent au lieu de le rejeter. Le rate limiting (limitation de débit) a un troisième frère — le quota, une allocation par période de facturation — et avec lui vous tenez le vocabulaire complet que la plupart des explications fondent en un seul mot. Ensemble, ces trois-là sont ce qui garde les API justes, rentables et en ligne.

Points clés

Ce que signifient la réponse 429 et les headers de rate limit

HTTP/1.1 429 Too Many Requests        ← RFC 6585
Retry-After: 30                       ← attendez ce délai (secondes ou une date)
X-RateLimit-Limit: 1000               ← votre budget pour cette fenêtre
X-RateLimit-Remaining: 0              ← ce qu'il en reste
X-RateLimit-Reset: 1767024000         ← quand il se recharge
RateLimit: "default";r=0;t=30         ← la forme standard émergente de l'IETF

La moitié du contrat qui revient au client — le code dont tout consommateur de SDK finit par avoir besoin :

// JavaScript / Node.js — Back4app JS SDK
// The client half of rate limiting: back off, with jitter, then retry
async function withBackoff(fn, attempt = 0) {
  try {
    return await fn();
  } catch (e) {
    if (e.code !== 155 || attempt >= 4) throw e;   // 155: request limit hit
    const wait = 2 ** attempt * 500 + Math.random() * 200;
    await new Promise((r) => setTimeout(r, wait)); // exponential + jitter
    return withBackoff(fn, attempt + 1);
  }
}
const results = await withBackoff(() => query.find());

// Flutter / Dart — Back4app Flutter SDK
// The client half of rate limiting: back off, with jitter, then retry
Future<ParseResponse> withBackoff(Future<ParseResponse> Function() fn,
    [int attempt = 0]) async {
  final response = await fn();
  if (response.success || attempt >= 4) return response;
  final wait = (1 << attempt) * 500 + Random().nextInt(200);
  await Future.delayed(Duration(milliseconds: wait)); // exponential + jitter
  return withBackoff(fn, attempt + 1);
}
final response = await withBackoff(() => query.query());

// iOS / Swift — Back4app Swift SDK
// The client half of rate limiting: back off, with jitter, then retry
func withBackoff<T>(_ attempt: Int = 0,
                    _ fn: @escaping () async throws -> T) async throws -> T {
  do { return try await fn() }
  catch {
    guard attempt < 4 else { throw error }
    let wait = pow(2.0, Double(attempt)) * 0.5 + .random(in: 0...0.2)
    try await Task.sleep(for: .seconds(wait))   // exponential + jitter
    return try await withBackoff(attempt + 1, fn)
  }
}
let results = try await withBackoff { try await query.find() }

// Android / Kotlin — Back4app Android SDK
// The client half of rate limiting: back off, with jitter, then retry
suspend fun <T> withBackoff(attempt: Int = 0, fn: suspend () -> T): T {
  return try {
    fn()
  } catch (e: ParseException) {
    if (attempt >= 4) throw e
    val wait = (1L shl attempt) * 500 + Random.nextLong(200)
    delay(wait)                                 // exponential + jitter
    withBackoff(attempt + 1, fn)
  }
}
val results = withBackoff { query.find() }

Token bucket vs. leaky bucket vs. fenêtre fixe vs. fenêtre glissante

Une note de bas de page distribuée que les diagrammes escamotent : avec plusieurs serveurs d’API, le bucket doit vivre dans un endroit partagé — typiquement un store en mémoire qui fait des incréments atomiques — et vous choisissez entre la précision stricte (chaque vérification interroge le store) et la vitesse (des compteurs locaux, une synchronisation lâche). La plupart des plateformes acceptent des limites légèrement lâches comme prix de la latence ; les quotas contractuels, eux, ont droit au traitement strict.

Portée : qui est limité, exactement ?

La limite par IP arrête les déferlantes anonymes et les fuites d’absorption DDoS, mais un NAT de bureau transforme des centaines d’utilisateurs en une seule adresse. La limite par clé associe les limites aux applications et aux plans de pricing — la portée qui fait le gros du travail. La limite par utilisateur empêche un compte de monopoliser la clé d’une app partagée. La limite par endpoint facture honnêtement les opérations coûteuses — les endpoints de recherche et d’export méritent des budgets plus serrés que les health checks. Les systèmes en production les superposent ; la question composite est toujours « quel budget cette requête a-t-elle dépensé ? »

Cas d’usage courants

• Protection des API publiques — le cas canonique : des budgets équitables par clé, publiés dans les headers, appliqués à la bordure.
• Application des tiers — plans gratuits vs. payants qui diffèrent précisément par le quota et la marge de burst.
• Défense contre l’abus et le scraping — des limites serrées pour les anonymes, généreuses pour les authentifiés.
• Contrôle des coûts sur les chemins coûteux — appels de LLM, exports, recherches : des budgets par endpoint qui reflètent le coût réel.
• Autodéfense côté client — backoff et fusion des requêtes face aux limites des autres, que vos intégrations doivent respecter pour ne pas se faire bannir.

Rejeter ou throttler ? Matrice de décision

Et la méta-règle : quel que soit votre choix, publiez-le — des limites dans la documentation et dans les headers transforment un mur frustrant en un contrat d’ingénierie sur lequel les clients peuvent bâtir.

Limites et trade-offs

• Les limites sont des instruments grossiers. Une requête n’est pas une unité de coût — une lecture bon marché et un export monstrueux dépensent « 1 » l’un comme l’autre. La limitation sensible au coût (des points par opération) est le raffinement, au prix de la complexité.
• La précision distribuée coûte de la latence. Les compteurs globaux stricts se sérialisent sur un store partagé ; les compteurs locaux lâches admettent trop de trafic à la marge. Choisissez selon la garantie visée, pas selon la mode.
• Les 429 punissent la boucle de nouvelles tentatives innocente. Les clients sans jitter se synchronisent en thundering herds ; le design de votre limiter doit supposer le pire client, parce qu’il le rencontrera.
• Le throttling masque la surcharge. Les requêtes mises en file lissent les graphiques tout en accumulant un backlog invisible ; les files d’attente ont besoin de bornes et de politiques de délestage, sinon elles se transforment en pannes différées.
• Les limites sont des décisions produit déguisées en ops. Budgets, tiers et marges de burst façonnent l’expérience utilisateur et le chiffre d’affaires — fixez-les avec la page de pricing ouverte, pas seulement le dashboard.

Le rate limiting sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. La protection est un comportement par défaut de la plateforme plutôt qu’un projet : les limites de requêtes s’appliquent à la bordure, par app et par plan, les opérations coûteuses peuvent être placées derrière des fonctions Cloud Code avec leurs propres vérifications, et les clients reçoivent une sémantique 429 propre — que le pattern de backoff côté SDK, dans les onglets de code ci-dessus, transforme en comportement résilient au lieu d’écrans en échec. Vous ajustez des politiques ; vous ne construisez pas le limiter.