Resumen ejecutivo

El 9 de octubre de 2026, entre las 09:50 y las 11:30 (UTC-3, Argentina), la plataforma procesó con demora eventos asíncronos que conectan algunos de sus servicios, impactando algunos cambios de estado de pedidos, notificaciones y webhooks. Las demoras fueron de entre 10 y 20 minutos durante la mayor parte de la ventana, con máximos cercanos a los 30 minutos durante algunos minutos.

Ningún evento se perdió: el mecanismo de procesamiento asíncrono cumplió su función de absorber el alto volumen de eventos y entregarlos todos con seguridad, pero su capacidad quedó temporalmente por debajo de una demanda que superó ampliamente lo previsto.

Las operaciones sincrónicas (API, Backoffice, toma de pedidos) no se vieron afectadas.

‌

Línea de tiempo (9 de octubre, hora de Argentina)

• 09:50 El volumen de eventos escala rápidamente por encima de la capacidad de procesamiento. Comienzan las demoras.
• 10:19 El monitoreo de Janis detecta el aumento en el tiempo de procesamiento. Se activa el equipo.
• 10:33 Se activa el protocolo de comunicación y comienza el diagnóstico.
• 10:40 - 11:05 Diagnóstico: se identifica un proceso de sincronización de configuración como origen del volumen. Las demoras alcanzan su máximo.
• 11:08 Se amplía la capacidad de procesamiento.
• 11:10 El proceso de sincronización finaliza.
• 11:30 Procesamiento normalizado. Los eventos se entregan sin demora.

Impacto

Los clientes que operaban durante la ventana vieron demoras en las acciones que dependen de eventos entre servicios: cambios de estado de pedidos, notificaciones y algunos webhooks hacia sus sistemas

• Demora en el procesamiento: entre 10 y 20 minutos durante la mayor parte de la ventana, con máximos cercanos a los 30 minutos durante algunos minutos.
• Eventos perdidos o con error: ninguno. Todos los eventos se procesaron una vez absorbido el volumen.
• Operaciones sincrónicas: sin impacto. API, Backoffice y toma de pedidos funcionaron con normalidad.

Causa raíz y factores contribuyentes

Causa raíz: la capacidad de procesamiento asíncrono estaba dimensionada para escalar automáticamente para atender una demanda de hasta 7 veces el volumen normal, pero la demanda real llegó a 9 veces de forma sostenida, con máximos de más de 20 veces. El mecanismo actuó como está diseñado (absorber el volumen sin perder eventos) pero generó demoras en el procesamiento.

Factores contribuyentes:

• Volumen por encima de lo proyectado. Un 9x sostenido frente a un margen de 7x está fuera del rango habitual de variación de la operación, requiriendo acción manual para aprobar un incremento extraordinario de capacidad.
• Sin priorización entre tipos de eventos. Los eventos de la operación compartieron la misma cola de procesamiento que algunos eventos de sincronización.

Acciones correctivas

• Se identificó el proceso de sincronización que originó el volumen y se amplió la capacidad de procesamiento durante el incidente hasta mitigarlo por completo.
• Acotar el volumen de eventos que genera el proceso de sincronización de configuración, para que no suceda nuevamente.
• Priorizar los eventos operativos sobre los de sincronización en el procesamiento asíncrono.