Cómo solucionar errores RPC 429 Too Many Requests

Qué significa un error RPC 429

HTTP 429 Too Many Requests es una respuesta de limitación de tráfico. Un proveedor RPC de blockchain puede aplicar límites por clave de API, cuenta, dirección IP, método, red, unidad de solicitud o intervalo de tiempo. Por eso, una ráfaga puede provocar respuestas 429 aunque el total diario de solicitudes parezca bajo.

Interpreta la respuesta como una señal de capacidad, no como un fallo temporal de red. Reintentar inmediatamente cada solicitud fallida aumenta la misma ráfaga que activó el límite y puede prolongar el incidente.

Identifica primero el alcance del límite

Antes de modificar el código de la aplicación, revisa el panel del proveedor y las cabeceras de respuesta. Registra la red, el método JSON-RPC, el endpoint, la región y la clave de API que produjeron el error. Compara el momento del fallo con despliegues, backfills de indexadores, picos de tráfico y tareas programadas.

• Confirma si el límite se mide en solicitudes, unidades de respuesta, unidades de cómputo o conexiones simultáneas.
• Separa el tráfico sostenido de las ráfagas breves; cada patrón necesita un control diferente.
• Identifica métodos costosos, como rangos amplios de eth_getLogs, llamadas trace o consultas de estado histórico.
• Comprueba si varios servicios comparten la misma clave de API o el mismo endpoint público.
• Revisa Retry-After y las cabeceras de límite específicas del proveedor cuando estén disponibles.

Reintenta de forma segura con backoff exponencial y jitter

Reintenta automáticamente solo las solicitudes de lectura idempotentes. Aumenta la espera después de cada fallo y añade jitter aleatorio para evitar que varios procesos vuelvan a intentarlo al mismo tiempo. Define un máximo de intentos y devuelve un error controlado cuando se agote el presupuesto de reintentos.

async function rpcRequest(url: string, body: unknown) {
  const maxAttempts = 5;

  for (let attempt = 0; attempt < maxAttempts; attempt += 1) {
    const response = await fetch(url, {
      method: "POST",
      headers: { "content-type": "application/json" },
      body: JSON.stringify(body),
    });

    if (response.ok) return response.json();
    if (response.status !== 429) throw new Error(`RPC failed: ${response.status}`);

    const retryAfter = Number(response.headers.get("retry-after"));
    const exponentialDelay = Math.min(500 * 2 ** attempt, 10_000);
    const jitter = Math.floor(Math.random() * 250);
    const delay = Number.isFinite(retryAfter)
      ? retryAfter * 1000
      : exponentialDelay + jitter;

    await new Promise((resolve) => setTimeout(resolve, delay));
  }

  throw new Error("RPC rate limit retry budget exhausted");
}

Reduce el tráfico RPC evitable

Los reintentos protegen frente a una ráfaga breve, pero no solucionan un uso excesivo sostenido. Reduce el número y el coste de las solicitudes antes de aumentar la capacidad.

• Almacena en caché resultados estables como chain IDs, metadatos de tokens, bloques finalizados y configuración de contratos.
• Deduplica solicitudes idénticas en curso para que los usuarios concurrentes compartan una sola llamada upstream.
• Agrupa lecturas JSON-RPC compatibles cuando el endpoint admita solicitudes por lotes.
• Usa suscripciones WebSocket para eventos en tiempo real en lugar de consultar cada bloque desde cada cliente.
• Divide rangos grandes de eth_getLogs en ventanas limitadas y guarda puntos de control para los rangos completados.
• Limita la concurrencia de los workers con una cola o un token bucket en lugar de iniciar todos los trabajos a la vez.

Diseña para la capacidad de producción

Un cliente RPC de producción debe combinar timeouts, reintentos limitados, límites de concurrencia, caché y observabilidad. Supervisa la tasa de 429, latencia, errores, unidades de solicitud, distribución de métodos y profundidad de la cola. Configura alertas antes de alcanzar un límite rígido de capacidad.

Mantén las cargas de desarrollo, staging, backfill y producción en claves o endpoints separados. Así evitas que una tarea de datos históricos consuma la capacidad necesaria para el tráfico de usuarios. Para aplicaciones críticas, utiliza un endpoint administrado con límites medibles y una ruta clara hacia infraestructura dedicada.

Cuándo aumentar la capacidad RPC

Aumenta la capacidad cuando el tráfico optimizado se acerque de forma constante al límite del plan, la latencia para usuarios crezca detrás de una cola o los métodos esenciales consuman más unidades de las que puede ofrecer un plan compartido. OnFinality ofrece endpoints RPC administrados con análisis de solicitudes y nodos dedicados para cargas que necesitan aislamiento.

Compara los planes RPC actuales en /pricing/rpc, explora las redes disponibles en /networks o crea un endpoint mediante el servicio API de OnFinality.