A las 12:03 AM la curva de pedidos en la pantalla de monitoreo subió como si alguien hubiera encendido una mecha. A las 12:07 llegó el primer 429: la API de etiquetas del transportista empezó a limitar el tráfico. Para las 12:12 la API de descarga de pedidos del marketplace también se negaba de forma intermitente. En la planta, una docena de empacadores esperaba las etiquetas de envío mientras las impresoras guardaban un silencio inquietante. El chico de TI reiniciaba trabajos y escribía "que no cunda el pánico" en el chat del grupo, y todos podían ver que estaba entrando en pánico. Aquella noche sobrevivimos dos horas con hojas de picking escritas a mano, y el servicio al cliente no dejó de sonar al día siguiente.
Esta no es una historia sobre software mal escrito. Es simplemente lo que hace la temporada pico: un sistema que llama a una API de terceros decenas de miles de veces al día puede alcanzar más de diez veces ese volumen en una sola noche. Cada API de terceros tiene cuotas, y cuando las superas, el otro lado no negocia: simplemente dice que no. Los pedidos dejan de entrar, las etiquetas dejan de imprimirse, el inventario deja de sincronizarse y toda tu operación se detiene frente a los servidores de otra empresa. Este artículo se salta la teoría. Esto es lo que realmente debes hacer antes de la temporada pico.
Las cuotas que nadie lee hasta la noche en que te matan
Primero: encuentra la cuota de cada API de terceros que llamas y anota los números. API de etiquetas de transportistas, descarga de pedidos de marketplaces, sincronización de inventario del ERP, notificaciones por SMS: cada una limita de forma distinta. Algunas por minuto, otras por día, algunas por cuenta, otras por IP. No te fíes de la memoria. No "creas que son unos cientos por minuto". Abre la documentación oficial, copia los números, anota las unidades.
Segundo: haz los cálculos. Toma el pico de la temporada pasada —o un ensayo menor como una venta de mitad de año— multiplícalo por 1.5 y calcula cuántas llamadas harás en esa hora de medianoche. Cuenta llamadas, no pedidos: un solo pedido puede significar tres o cuatro llamadas a la API (consulta de tarifa, etiqueta, envío de tracking, actualización de inventario), y ese multiplicador sorprende a la mayoría la primera vez que lo calculan. Pon el resultado junto a la cuota y la brecha te mira de frente.
Tercero: solicita aumentos de cuota con tiempo. Las grandes plataformas y transportistas admiten aumentos previos a la temporada pico, pero llevan un proceso y una cola: dos o tres semanas de antelación es sentido común. No envíes solo un número; adjunta tus cálculos. El ingeniero que revise tu solicitud responde mucho mejor a "volumen de llamadas en hora pico, duración, desglose por endpoint" que a "por favor suban nuestra cuota". Una la aprendí por las malas: un año subimos la cuota de nuestro transportista principal y nos olvidamos del carril de respaldo. La noche pico el principal flaqueó, el tráfico conmutó por error y la cuota del respaldo voló al instante. Toda esa preparación, desperdiciada. Cubre cada cuenta y cada ruta que vayas a llamar de verdad, incluidos los respaldos.
Los reintentos no deberían ser pollos sin cabeza
Un aumento de cuota no te hace a prueba de balas. La noche pico siempre trae sorpresas: los servidores del otro lado tambalean, se pierden paquetes, un endpoint se degrada sin avisar. Cómo esté escrita tu lógica de reintentos decide si pasas rozando o si terminas de tumbarlos.
Nunca escribas reintentos tontos a intervalos fijos. Cada solicitud fallida reintentando cada cinco segundos solo devuelve la inundación contra el muro: en cuanto el otro lado recupera el aliento, lo vuelves a tumbar. Usa retroceso exponencial: espera un segundo, luego dos, luego cuatro, duplicando hacia arriba, con un poco de jitter aleatorio mezclado. La gente se salta el jitter y no debería: sin él, todos los clientes reintentan en el mismo instante y obtienes una nueva inundación sincronizada. Con él, los reintentos se dispersan.
El backoff también necesita un techo: un número máximo de reintentos y una espera total máxima, pasado lo cual te rindes y degradas. El reintento infinito es el patrón más peligroso que existe. Una vez vi crecer una cola de reintentos hasta comerse la memoria del servidor de aplicaciones: nuestro propio sistema se cayó antes de que la API del proveedor se recuperara. Fija el número de reintentos y los tiempos de espera en la configuración durante las pruebas de carga. Editar la configuración la noche pico es jugar a la ruleta.
Y trata las lecturas y las escrituras de forma distinta. Reintentar una descarga de pedidos es barato. Reintentar una impresión de etiqueta o un decremento de inventario no lo es: así que pregunta por la idempotencia antes de reintentar una escritura. Si el mismo pedido se imprime dos veces, ¿el transportista lo deduplica o recibes dos etiquetas? ¿Te cobran dos veces? Nadie hace estas preguntas un martes tranquilo; la noche pico te enseñará la lección por ti. Las claves de idempotencia van en cada llamada de escritura que toque dinero o mercancía física. No descubras los duplicados en la conciliación.
Cuando de verdad se rompe, degrada con dignidad
El backoff y las colas compran tiempo. La degradación admite la realidad: su API está caída y tu almacén no puede parar. El plan de degradación se escribe y se ensaya antes de la temporada pico, no se inventa a las 12:12 AM.
La jugada de cabecera es "toma el pedido ahora, sincroniza después". ¿No puedes descargar los pedidos del marketplace? Produce con los pedidos en caché local, imprime etiquetas con el transportista de respaldo y rellena los datos cuando la API se recupere. ¿Sincronización de inventario atascada? Sigue enviando, registra las discrepancias, concilia a mano después. Un principio: protege la línea vital, la mercancía saliendo por la puerta. Todo lo que no sea en tiempo real puede ir con retraso.
La degradación debería tener niveles. Leve: elimina las llamadas no críticas —pasa las notificaciones por SMS a un lote posterior a la temporada y libera la cuota para la impresión de etiquetas, la llamada que te mantiene vivo. Media: conmuta al carril de respaldo aunque sea más lento o más caro. Grave: pasa a manual —etiquetas en blanco rellenadas a mano, picks dirigidos por hoja de cálculo. Suena primitivo, pero cuando estás ahí, un plan primitivo le gana a mirar una pantalla muerta. El disparador y los pasos de cada nivel caben en una hoja impresa pegada al escritorio de guardia. Nadie piensa con claridad a medianoche en la noche pico.
Debajo de todo hay una cola. Cada llamada que normalmente va directa a un tercero debería pasar primero por una cola local durante la temporada pico, consumida a un ritmo constante por debajo de la cuota. Pon marcas de alerta en la profundidad de la cola: pasada la línea, la degradación leve entra automáticamente. Construye esto en tiempos normales, no la semana antes del pico: la estabilidad de la propia cola y su monitoreo necesitan tiempo para probarse.
A dos semanas, repasa esta lista
Aquí está la lista de verificación previa al pico, lista para tachar: cada cuota de terceros anotada; volumen de llamadas pico calculado; solicitudes de aumento presentadas, carriles de respaldo incluidos; política de reintentos activa —retroceso exponencial con jitter y techo duro; idempotencia de llamadas de escritura confirmada; los tres niveles de degradación escritos y ensayados una vez; la cola de suavizado activa con marcas de alerta puestas; el roster de guardia y la ruta de escalación publicados.
Una cosa que puedes hacer mañana: abre la configuración de integraciones de terceros de tu sistema, encuentra el límite de cuota de cada API y arma la tabla. Esa única tabla es la diferencia entre dormir la noche antes de la temporada pico y vivir otra noche como la que abrí este artículo.
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
