Límites de API del piloto a producción: backoff sin quemar prepaid

Un 429 no invita a martillar la API de envío hasta que algo pase. En prepaid, una tormenta de reintentos es un evento de cartera: OTP duplicado, alertas apiladas, filas de ledger sin emparejar. Los límites existen para que producto, ingeniería y finanzas compartan un techo. De piloto a producción no es «quitar el tope» — límites contratados, backoff que respeta idempotencia, claves sandbox y producción separadas, y una ventana de replay de webhook que no doble-debita. Véase idempotencia, reintentos y dinero.

IOSOR es prepaid white-label: llamadas autenticadas, débitos correlacionables, errores seguros para el cliente que nunca vuelcan cargas de otra marca.

Los límites protegen prepaid, no son un fallo

Los límites acotan cuántos intentos aceptados golpean la cartera por ventana — no cuántos intentos TCP hizo el balanceador. Documenten la ventana (por clave, cuenta, clase de destino), el código y Retry-After. Un cliente que trata 429 como «inténtalo más fuerte» corre contra finanzas. Exporten rechazos de límite junto a débitos exitosos.

Backoff sin segundo débito: límites con idempotencia

Backoff exponencial sin clave de idempotencia es cómo una red inestable se vuelve dos OTP. La clave es única por intento de negocio, no por intento TCP, y devuelve el mismo resultado aceptado dentro de un TTL claro. El reenvío de usuario es otra acción de producto con su propio límite. El stop por saldo bajo sigue: un reintento no debe perforar una cartera vacía.

Límites de piloto frente a producción

Las claves de piloto deben ser más estrictas: bajo volumen, visibilidad rápida, errores baratos. Los límites de producción se contratan para los corredores que realmente corren. Subir un techo es un cambio de cuenta con dueño. Las pruebas de carga pertenecen a claves sandbox; una clave de producción en un soak quema prepaid. No prometan QPS de producción mientras el corredor del catálogo esté in setup.

Claves y replay de webhook en el mismo corte

Los límites de envío no salvan si el consumidor de webhook procesa dos veces un DLR. Corte: congelar tráfico sandbox, emitir claves de producción, apuntar webhooks a consumidores de producción, verificar firmas, acotar la ventana de replay, luego un intento real. Un callback repetido a las 02:00 debe ser no-op, no un segundo débito. Secretos separados; nunca los peguen en un ticket.

Señales de alarma

• «Reintentar hasta 200» sin clave de idempotencia
• 429 tratado como un 200 suave
• Clave de producción en una prueba de carga o URL de webhook sandbox en producción
• Ventana de replay medida en semanas, o callbacks sin firma «para el piloto»
• Reenvío de usuario mezclado en el presupuesto de auto-reintento
• Errores de cara al cliente que vuelcan códigos crudos de arriba

Empezar con IOSOR

Anote la ventana de límite — por clave, cuenta o clase de destino — y el Retry-After que honrará. Fuerce un 429, haga backoff y reintente la misma intención con la misma Idempotency-Key. El ledger debe mostrar un débito. Cambie la clave sandbox por la de production antes de subir ningún techo.

• Rastreo de IDs de correlación desde solicitudes API hasta webhooks DLR
• Simulación de latencia y errores de DLR en pruebas locales

Conclusión IOSOR

Haga: trate el 429 como una pausa con Retry-After, no como un éxito blando. Empareje cada backoff con la clave original para que prepaid vea una intención aceptada.

No haga: subir límites de production con una clave de prueba de carga, ni martillar hasta 200 sin clave hasta que la cartera parezca uso extra.