Che cosa sono il rate limiting e il throttling delle API?

Il rate limiting è un controllo che limita quante richieste può fare un client per finestra; il throttling rallenta l’eccesso invece di rifiutarlo. Aggiungendo il terzo fratello – la quota, un’assegnazione per periodo di fatturazione – si ottiene il vocabolario completo che la maggior parte delle spiegazioni fonde in una sola parola. Insieme sono il modo in cui le API restano eque, sostenibili e raggiungibili.

Punti chiave

Che cosa significano la risposta 429 e gli header di rate limit

HTTP/1.1 429 Too Many Requests        ← RFC 6585
Retry-After: 30                       ← attendere questo tempo (secondi o una data)
X-RateLimit-Limit: 1000               ← il budget di questa finestra
X-RateLimit-Remaining: 0              ← quanto ne resta
X-RateLimit-Reset: 1767024000         ← quando si ricarica
RateLimit: "default";r=0;t=30         ← la forma standard IETF emergente

La metà del contratto che spetta al client – il codice di cui ogni consumatore di SDK finisce per avere bisogno:

// 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. finestra fissa vs. finestra scorrevole

Una nota a piè di pagina distribuita che i diagrammi saltano: con molti server API il bucket deve vivere in un posto condiviso – tipicamente uno store in memoria che esegue incrementi atomici – e la scelta è tra precisione rigorosa (ogni verifica interroga lo store) e velocità (contatori locali, sincronizzazione lasca). La maggior parte delle piattaforme accetta limiti leggermente laschi come prezzo della latenza; le quote contrattuali ricevono il trattamento rigoroso.

Ambito: chi viene limitato, esattamente?

Il limite per IP ferma le ondate anonime e le perdite nell’assorbimento di un DDoS, ma il NAT di un ufficio trasforma centinaia di utenti in un solo indirizzo. Il limite per chiave lega i limiti alle applicazioni e ai piani di prezzo – l’ambito che fa il lavoro grosso. Il limite per utente impedisce a un singolo account di monopolizzare la chiave di un’app condivisa. Il limite per endpoint dà un prezzo onesto alle operazioni costose – gli endpoint di ricerca ed export meritano budget più stretti degli health check. I sistemi in produzione li stratificano; la domanda composita è sempre “quale budget ha speso questa richiesta?”

Casi d’uso tipici

• Protezione delle API pubbliche – il caso canonico: budget equi per chiave, pubblicati negli header, applicati al confine.
• Applicazione dei piani – piani gratuiti vs. a pagamento che differiscono esattamente per quota e margine di burst.
• Difesa da abusi e scraping – limiti stretti per il traffico anonimo, generosi per quello autenticato.
• Controllo dei costi sui percorsi costosi – chiamate a LLM, export, ricerche: budget per endpoint che riflettono il costo reale.
• Autodifesa lato client – backoff e accorpamento delle richieste di fronte ai limiti degli altri, che le proprie integrazioni devono rispettare per non finire bandite.

Rifiutare o throttlare? Matrice decisionale

E la meta-regola: qualunque sia la scelta, va pubblicata – limiti nella documentazione e negli header trasformano un muro frustrante in un contratto ingegneristico su cui i client possono costruire.

Limiti e trade-off

• I limiti sono strumenti grossolani. Una richiesta non è un’unità di costo – una lettura economica e un export mostruoso spendono entrambi “1”. La limitazione consapevole del costo (punti per operazione) è il raffinamento, al prezzo della complessità.
• La precisione distribuita costa latenza. I contatori globali rigorosi si serializzano su uno store condiviso; quelli locali laschi ammettono troppo traffico al margine. Conviene scegliere in base alla garanzia, non alla moda.
• I 429 puniscono il ciclo di ritentativi innocente. I client senza jitter si sincronizzano in thundering herd; il design di un limiter deve presupporre il peggiore dei client, perché lo incontrerà.
• Il throttling nasconde il sovraccarico. Le richieste accodate appianano i grafici mentre accumulano un backlog invisibile; le code hanno bisogno di limiti e di politiche di scarto, altrimenti diventano disservizi differiti.
• I limiti sono decisioni di prodotto in abiti da ops. Budget, piani e margini di burst plasmano l’esperienza utente e il fatturato – conviene fissarli con la pagina dei prezzi aperta, non solo con la dashboard.

Il rate limiting su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. Qui la protezione è un’impostazione predefinita della piattaforma più che un progetto: i limiti di richiesta si applicano al confine, per app e per piano, le operazioni costose possono essere messe dietro funzioni Cloud Code con controlli propri, e i client ricevono una semantica 429 pulita – che il pattern di backoff lato SDK, nelle schede di codice qui sopra, trasforma in comportamento resiliente invece che in schermate in errore. Le politiche si regolano; il limiter non si costruisce.