¿Qué es Rate Limiting & Throttling de API?

Rate limiting es un control que limita cuántas solicitudes puede hacer un cliente por ventana de tiempo; throttling desacelera el exceso en vez de rechazarlo. Suma el tercer hermano — la cuota, una asignación por período de facturación — y tienes el vocabulario completo que la mayoría de las explicaciones difumina en una sola palabra. Juntos son lo que mantiene a las APIs justas, solventes y en línea.

Puntos clave

Qué significan la respuesta 429 y los headers de rate limit

HTTP/1.1 429 Too Many Requests        ← RFC 6585
Retry-After: 30                       ← espera este tiempo (segundos o una fecha)
X-RateLimit-Limit: 1000               ← tu presupuesto en esta ventana
X-RateLimit-Remaining: 0              ← lo que queda
X-RateLimit-Reset: 1767024000         ← cuándo se recarga
RateLimit: "default";r=0;t=30         ← la forma estándar emergente del IETF

La mitad del contrato que le toca al cliente — el código que todo consumidor de SDK termina necesitando:

// 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. ventana fija vs. ventana deslizante

Una nota al pie distribuida que los diagramas omiten: con muchos servidores de API, el bucket debe vivir en algún lugar compartido — típicamente un store en memoria haciendo incrementos atómicos — y eliges entre precisión estricta (cada chequeo consulta el store) y velocidad (contadores locales, sincronización laxa). La mayoría de las plataformas acepta límites ligeramente laxos como el precio de la latencia; las cuotas contractuales reciben el tratamiento estricto.

Alcance: ¿a quién exactamente se limita?

Por IP frena avalanchas anónimas y fugas de absorción de DDoS, pero un NAT de oficina convierte a cientos de usuarios en una sola dirección. Por clave mapea límites a aplicaciones y planes de precios — el alcance que carga con el trabajo pesado. Por usuario evita que una cuenta monopolice la clave de una app compartida. Por endpoint pone un precio honesto a las operaciones caras — los endpoints de búsqueda y de export merecen presupuestos más ajustados que los health checks. Los sistemas de producción los combinan en capas; la pregunta compuesta siempre es “¿qué presupuesto gastó esta solicitud?”

Casos de uso comunes

• Protección de APIs públicas — el caso canónico: presupuestos justos por clave, publicados en headers, aplicados en el borde.
• Aplicación de tiers — planes gratuitos vs. de pago que difieren precisamente en cuota y margen de burst.
• Defensa contra abuso y scraping — límites estrictos para anónimos, generosos para autenticados.
• Control de costos en rutas caras — llamadas a LLM, exports, búsquedas: presupuestos por endpoint que reflejan el costo real.
• Autodefensa del lado del cliente — backoff y coalescencia de solicitudes frente a los límites de otros, que tus integraciones deben respetar para no ser bloqueadas.

¿Rechazar o hacer throttling? Matriz de decisión

Y la metarregla: elijas lo que elijas, publícalo — los límites en la documentación y en los headers convierten un muro frustrante en un contrato de ingeniería contra el cual los clientes pueden construir.

Limitaciones y trade-offs

• Los límites son instrumentos toscos. Una solicitud no es una unidad de costo — una lectura barata y un export monstruoso gastan “1” cada uno. La limitación sensible al costo (puntos por operación) es el refinamiento, al precio de la complejidad.
• La precisión distribuida cuesta latencia. Los contadores globales estrictos se serializan sobre un store compartido; los locales laxos admiten de más en los márgenes. Elige por garantía, no por moda.
• Los 429 castigan al loop de reintentos inocente. Los clientes sin jitter se sincronizan en thundering herds; el diseño de tu limiter debe asumir al peor cliente, porque lo va a encontrar.
• El throttling esconde la sobrecarga. Las solicitudes encoladas suavizan las gráficas mientras acumulan backlog invisible; las colas necesitan topes y políticas de descarte, o se convierten en retrasos de outage.
• Los límites son decisiones de producto vestidas de ops. Presupuestos, tiers y márgenes de burst moldean la experiencia de usuario y los ingresos — defínelos con la página de precios abierta, no solo con el dashboard.

Rate limiting en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. La protección es un valor por defecto de la plataforma, no un proyecto tuyo: los límites de solicitudes se aplican en el borde por app y por plan, las operaciones caras pueden quedar detrás de funciones Cloud Code con sus propios chequeos, y los clientes reciben una semántica 429 limpia — que el patrón de backoff del lado del SDK, en las pestañas de código de arriba, convierte en comportamiento resiliente en vez de pantallas rotas. Tú ajustas políticas; no construyes el limiter.