O que é Rate Limiting & Throttling de API?

Rate limiting é um controle que limita quantas requisições um cliente pode fazer por janela de tempo; throttling desacelera o excesso em vez de rejeitá-lo. Some o terceiro irmão — a cota, uma franquia por período de cobrança — e você tem o vocabulário completo que a maioria das explicações embaralha numa palavra só. Juntos, eles são o que mantém as APIs justas, solventes e no ar.

Principais pontos

O que significam a resposta 429 e os headers de rate limit

HTTP/1.1 429 Too Many Requests        ← RFC 6585
Retry-After: 30                       ← espere esse tempo (segundos ou uma data)
X-RateLimit-Limit: 1000               ← seu orçamento nesta janela
X-RateLimit-Remaining: 0              ← o que resta
X-RateLimit-Reset: 1767024000         ← quando ele renova
RateLimit: "default";r=0;t=30         ← a forma padrão emergente do IETF

A metade do contrato que cabe ao cliente — o código de que todo consumidor de SDK acaba precisando:

// 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. janela fixa vs. janela deslizante

Uma nota de rodapé distribuída que os diagramas pulam: com muitos servidores de API, o balde precisa viver em algum lugar compartilhado — tipicamente um store em memória fazendo incrementos atômicos — e você escolhe entre precisão estrita (toda checagem consulta o store) e velocidade (contadores locais, sincronização frouxa). A maioria das plataformas aceita limites levemente frouxos como o preço da latência; cotas contratuais recebem o tratamento estrito.

Escopo: quem exatamente é limitado?

Por IP barra enxurradas anônimas e vazamento de absorção de DDoS, mas um NAT de escritório transforma centenas de usuários num único endereço. Por chave mapeia limites a aplicações e planos de preço — o escopo que carrega o piano. Por usuário impede que uma conta monopolize a chave de um app compartilhado. Por endpoint precifica operações caras com honestidade — endpoints de busca e export merecem orçamentos mais apertados que health checks. Sistemas de produção os combinam em camadas; a pergunta composta é sempre “qual orçamento esta requisição gastou?”

Casos de uso comuns

• Proteção de API pública — o caso canônico: orçamentos justos por chave, publicados em headers, aplicados na borda.
• Aplicação de tiers — planos gratuitos vs. pagos que diferem precisamente em cota e folga de burst.
• Defesa contra abuso e scraping — limites apertados para anônimos, generosos para autenticados.
• Controle de custo em caminhos caros — chamadas de LLM, exports, buscas: orçamentos por endpoint que refletem o custo real.
• Autodefesa no lado do cliente — backoff e coalescência de requisições contra os limites dos outros, que suas integrações precisam respeitar para não serem banidas.

Rejeitar ou fazer throttling? Matriz de decisão

E a meta-regra: seja qual for a escolha, publique-a — limites na documentação e nos headers transformam um muro frustrante num contrato de engenharia contra o qual os clientes conseguem construir.

Limitações e trade-offs

• Limites são instrumentos rombudos. Uma requisição não é uma unidade de custo — uma leitura barata e um export monstruoso gastam “1” cada. Limitação sensível a custo (pontos por operação) é o refinamento, pelo preço da complexidade.
• Precisão distribuída custa latência. Contadores globais estritos serializam num store compartilhado; contadores locais frouxos admitem demais nas margens. Escolha por garantia, não por moda.
• 429s punem o loop de retry inocente. Clientes sem jitter se sincronizam em thundering herds; o design do seu limiter precisa assumir o pior cliente, porque vai encontrá-lo.
• Throttling esconde a sobrecarga. Requisições enfileiradas suavizam os gráficos enquanto acumulam backlog invisível; filas precisam de limites e políticas de descarte, ou viram atrasos de outage.
• Limites são decisões de produto vestidas de ops. Orçamentos, tiers e folgas de burst moldam experiência do usuário e receita — defina-os com a página de preços aberta, não só com o dashboard.

Rate limiting no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. Proteção é um padrão da plataforma, não um projeto seu: limites de requisição se aplicam na borda por app e por plano, operações caras podem ficar atrás de funções Cloud Code com checagens próprias, e os clientes recebem uma semântica 429 limpa — que o padrão de backoff no lado do SDK, nas abas de código acima, transforma em comportamento resiliente em vez de telas quebradas. Você ajusta políticas; não constrói o limiter.