Guía práctica para implementar retries exponenciales y circuit breaker en integraciones entre ERP y marketplaces

Por Kevin Marcondes · Publicado el 28/10/2026 · 8 min de lectura

Esta guía práctica muestra cómo aplicar retries exponenciales y circuit breaker en integraciones entre ERP y marketplaces para mantener resiliencia sin duplicar pedidos ni violar límites de API. Verás cuándo usar cada patrón, cómo configurar backoff con jitter, diseñar idempotencia y monitorizar. Útil para equipos técnicos y responsables de negocio.

Cuándo usar retries y circuit breaker en integraciones ERP–marketplaces

Las integraciones con marketplaces sufren timeouts, picos de tráfico, ventanas fiscales y límites de tasa. Retries exponenciales y circuit breaker estabilizan el flujo, evitan caídas en cascada y reducen retrabajo.

Señales de que necesitas estos patrones: errores 429/5xx frecuentes, duplicación de pedidos, stock desincronizado, picos de latencia y ventanas de facturación sensibles al tiempo.

En escenarios de alto volumen, combinar con colas ayuda a desacoplar y nivelar picos. Revisa la comparativa de colas en Amazon SQS vs RabbitMQ gestionado para elegir la mejor opción.

• APIs con rate limit agresivo (429) en el cierre de mes.
• Time‑outs intermitentes y DNS fallando esporádicamente.
• POSTs que, al reprocesar, generan pedidos duplicados.
• Procesos nocturnos que congestionan integraciones e informes.

Backoff exponencial con jitter: parámetros y ejemplo

Retries simples con intervalos fijos amplifican la congestión. Usa backoff exponencial con jitter para espaciar intentos y evitar ráfagas sincronizadas. A cada fallo, el tiempo de espera aumenta y un ruido aleatorio (jitter) dispersa las reintentos.

Parámetros prácticos: intentos máximos, factor de crecimiento, límite superior, tipo de jitter (full o equal) y deadline total de la operación. Respeta siempre el rate limit del marketplace y aborta con un error claro cuando el deadline expire.

Referencias útiles: Exponential Backoff and Jitter (AWS) y la guía de backoff de Google Cloud.

• Max attempts: define un tope para fallos reales.
• Base delay y factor: por ejemplo, 200 ms y factor 2.
• Max backoff: evita esperas excesivas.
• Jitter: “full” reduce sincronización entre clientes.
• Deadline total: cancela si el tiempo de negocio se supera.

function retryWithExponentialBackoff(op, isRetryable, maxAttempts=6,
                                      base=0.2s, factor=2, maxDelay=10s,
                                      jitter='full', deadline=30s) {
  start = now()
  attempt = 1
  while (true) {
    try {
      return op()
    } catch (err) {
      if (attempt >= maxAttempts || !isRetryable(err)) throw err
      elapsed = now() - start
      if (elapsed > deadline) throw DeadlineExceeded
      // Exponential delay
      delay = min(maxDelay, base * (factor ** (attempt - 1)))
      // Jitter
      if (jitter == 'full') delay = random(0, delay)
      if (jitter == 'equal') delay = (delay / 2) + random(0, delay / 2)
      sleep(delay)
      attempt++
    }
  }
}

Idempotencia: evitando pedidos y actualizaciones duplicadas

Los retries solo son seguros con operaciones idempotentes. Para POSTs, genera una clave de idempotencia por pedido/entidad y persiste el resultado asociado. Así, reenvíos producen el mismo efecto sin duplicar.

Diseña el ERP para registrar procesamientos con claves únicas y metadatos: estado final, payload normalizado, timestamp y TTL opcional cuando aplique. Nunca reenvíes un POST sin idempotencia.

Para flujos asíncronos, usa colas y control de deduplicación. Entiende los trade‑offs de entrega eventual y claves idempotentes consultando prácticas sobre entrega eventual entre ERP y tienda virtual.

• Define el alcance de la clave: por pedido, ítem, factura u operación.
• Almacena hash del payload para detectar diferencias sutiles.
• Devuelve 200/201 con el mismo body cuando se reprocesa.
• Expira claves cuando el dominio lo permita.
• Incluye la clave en logs y métricas para trazabilidad.

Circuit breaker en la práctica: estados, umbrales y fallback

El circuit breaker evita sobrecargar servicios inestables. Estados: cerrado (normal), abierto (bloquea llamadas) y half‑open (pruebas limitadas). Se abre al detectar una tasa de fallo alta en una ventana deslizante.

Define umbrales claros: tasa de error, timeouts sucesivos, volumen mínimo y duración de apertura. Planifica un fallback específico para cada operación crítica.

Estrategias comunes: encolar para reprocesado, servir cache reciente o degradar funcionalidad (p. ej., pausar actualización de imágenes y mantener precio/stock).

• Ventana deslizante con N llamadas mínimas para tener estadística.
• Error compuesto: 5xx, timeouts y 429 cuentan; 4xx de validación no.
• Half‑open con pocas pruebas y espaciamiento mayor.
• Backoff antes de volver a intentar reabrir tras el periodo de enfriamiento.
• Expone el estado del breaker en métricas y healthchecks.

class CircuitBreaker {
  state = 'CLOSED'
  openedAt = null
  failureCount = 0
  successCount = 0
  function call(fn, isRetryable) {
    if (this.state == 'OPEN') {
      if (now() - this.openedAt < cooldown) throw OpenCircuit
      this.state = 'HALF_OPEN'
      this.failureCount = 0; this.successCount = 0
    }
    try {
      res = retryWithExponentialBackoff(fn, isRetryable)
      if (this.state == 'HALF_OPEN') this.successCount++
      if (this.successCount >= halfOpenSuccesses) this.close()
      return res
    } catch (e) {
      this.failureCount++
      if (this.shouldOpen()) this.open()
      throw e
    }
  }
  function shouldOpen() { return this.failureRate() > threshold && this.sampleSize() >= minSamples }
  function open() { this.state = 'OPEN'; this.openedAt = now() }
  function close() { this.state = 'CLOSED'; this.failureCount = 0; this.successCount = 0 }
}

Qué error merece retry: tabla de decisión

No todo error debe reintentarse. Clasifica primero. Abajo, un mapa práctico para integraciones ERP–marketplaces. Ajusta según las políticas de cada API y los contratos de negocio.

Observabilidad: métricas, logs estructurados y correlación

Sin visibilidad, los retries se convierten en una caja negra. Instrumenta cada integración con métricas, logs y trazas. Usa correlación para seguir una petición de extremo a extremo, del ERP al marketplace.

Estructura logs en JSON con clave de idempotencia, correlación, intentos, delays y estado del breaker. Centraliza y visualiza métricas para detectar saturación y regressiones.

• Métricas: intentos, éxitos por operación, errores por categoría.
• Histogramas de delay y latencia end‑to‑end.
• Gauges: estado del breaker y duración abierto.
• Alertas por tasa de error y saturación de rate limit.
• Dashboards por marketplace, operación y cuenta.

Pruebas, simulación de fallos y rollout seguro

Prueba retries y circuit breaker bajo fallos reales. Simula 429, 5xx, time‑outs, jitter extremo y lentitud controlada. Valida que el sistema no duplica pedidos y respeta los deadlines de negocio.

Aplica rollout progresivo: feature flags por marketplace/operación, métricas comparativas y reversión sencilla. En sistemas legados, las flags permiten activar por cuenta o ruta.

• Sandbox del marketplace siempre que sea posible.
• Pruebas de carga enfocadas en picos y ventanas fiscales.
• Fault injection: simular caída de DNS y variar latencia.
• Canary por porcentaje de cuentas/tiendas.
• Runbook de incidentes con pasos y contactos.

Preguntas frecuentes

¿Cómo decidir el número de intentos y el intervalo del backoff?

Básate en el SLO de la operación y en los límites del marketplace. Usa pocos intentos con backoff exponencial y jitter, un límite superior de espera y un deadline total. Si la ventana de negocio es corta, prefiere menos intentos y un fallback rápido a cola o revisión.

¿El circuit breaker no oculta problemas al equipo?

No: evita colapsos mientras señala el riesgo. Expón métricas de estado, tasa de fallos y motivo de apertura. Genera alertas claras para que el equipo actúe en la causa raíz. El breaker contiene, no corrige definitivamente.

¿Cómo evitar duplicaciones al repetir POSTs?

Implementa idempotencia: genera una clave por operación de negocio, persiste el resultado y responde consistentemente en reenvíos. En incertidumbre de estado (timeout), reintenta con la misma clave o consulta el recurso antes de reenviar. Sin idempotencia, no hagas retry de POST.

¿Debo usar siempre cola con retries y circuit breaker?

No siempre. La cola desacopla picos y facilita reprocesos, pero añade complejidad. En integraciones críticas o de alto volumen, las colas ayudan. Evalúa plazos, volumen y SLAs del marketplace para decidir acoplamiento y patrones de reproceso.

¿Cuándo dejar de intentar y generar error para el usuario u operador?

Deja de intentar cuando se alcance el deadline de negocio, el número máximo de intentos o el breaker se abra. Registra el motivo, alimenta una cola de revisión si aplica y notifica al operador con datos para acción (error categorizado, operación y marketplace).

Ver también

• Guía práctica: configurar failover activo‑pasivo entre dos VPS con Keepalived, HAProxy y lsyncd para uploads sincronizados
• Guía: checklist técnico para preparar un VPS Debian con Docker Compose para aplicaciones PHP en producción
• Guía práctica para dimensionamiento de VPS y tuning de PHP‑FPM para tiendas Magento/OpenMage con picos estacionales: del dimensionamiento a la prueba de carga
• Guía de backup y recuperación PostgreSQL con wal‑shipping y basebackup en VPS con espacio limitado: práctica de bajo uso de disco