Cuando una dependencia se va al traste: nuestro postmortem del incidente del 22 y 23 de junio

La cronología alineada

Hora (UTC)	Qué ocurrió aguas arriba (Informe completo)	Qué ocurrió internamente / nuestra experiencia
22 de junio, 19:00	El desencadenante: la escasez de capacidad de AWS en us-east-1 obliga a acumular ~10,000 ejecuciones en las colas aguas arriba.	Nuestras tareas en segundo plano empiezan a atascarse en silencio. Las colas empiezan a crecer por debajo del capó.
22 de junio, 20:09	El colapso: el plano de control de Kubernetes aguas arriba llega al 100% de CPU, pierde el quorum de la base de datos y **us-east-1** se cae por completo.	Nuestro entorno de producción deja de procesar ejecuciones. Miles de tareas en toda la plataforma quedan bloqueadas en cola.
22 de junio, 21:58	El equipo de ingeniería aguas arriba está luchando activamente contra un bucle de "tormenta de reconexión".	Incidente comunicado: se detectan tasas elevadas de fallos y se pone en marcha una sala interna de incidentes.
23 de junio, 00:59	El proveedor aguas arriba recomienda a los usuarios mover manualmente sus cargas de trabajo a la región eu-central-1.	Se asigna un responsable del incidente: la sala de respuesta al incidente queda completamente activada con un responsable asignado para gestionar la evaluación entre regiones.
23 de junio, 01:01 - 02:10	El proveedor aguas arriba despliega una actualización de emergencia del panel para permitir mover ejecuciones en bloque entre regiones.	Mitigación activa: a las 01:10, el equipo cancela manualmente nuestras ejecuciones en cola de EE. UU. para liberar la capacidad de ejecución bloqueada de nuestra cuenta y redirige todo el tráfico nuevo a la región europea. A las 02:10, los mensajes vuelven a procesarse.
23 de junio, 02:02 - 02:33	El proveedor aguas arriba amplía manualmente el almacenamiento de respaldo de su base de datos.	La gravedad sube a crítica: ahora hay más de 30,000+ de nuestras propias tareas en cola y esperando. El equipo publica una actualización de estado crítica en nuestra página pública de estado.
23 de junio, 04:35 - 05:05	Las actualizaciones de la infraestructura aguas arriba ralentizan la ejecución hasta volverla un goteo.	El cuello de botella de los webhooks: la tasa de procesamiento cae. A las 05:05, identificamos que nuestra cola de entrega de webhooks es el principal cuello de botella que se niega a vaciarse.
23 de junio, 08:38	La segunda cascada: el tráfico global redirigido satura la región europea del proveedor, dejándola completamente fuera de línea.	Parón total: ahora ambas regiones aguas arriba están, en la práctica, caídas. Tenemos más de 13,000+ tareas congeladas en vuelo, totalmente a merced de la recuperación aguas arriba.
23 de junio, 10:34	El equipo de ingeniería aguas arriba lucha por volver a poner en línea su región europea.	Despliegue del interruptor de corte: al ver que la capa principal de procesamiento en segundo plano está completamente bloqueada, nuestro equipo pasa de la mitigación de infraestructura a una derivación arquitectónica. Desplegamos un hotfix de emergencia en todos los entornos principales de la aplicación y la API para desactivar temporalmente la gestión asíncrona de tareas.
23 de junio, 10:41	El proveedor aguas arriba sigue trabajando en redimensionar los nodos de su plano de control.	Alivio inmediato: la derivación arquitectónica funciona a la perfección. Al rodear las colas congeladas de fondo, los procesos críticos de la aplicación pasan a rutas de ejecución directa. Ingeniería lo confirma: "Emails are flowing again."
23 de junio, 17:06	El proveedor aguas arriba por fin estabiliza ambas regiones y restaura las velocidades de procesamiento.	Cola vaciada: ingeniería confirma que nuestras colas en ambas regiones se han vaciado por completo. El rendimiento del sistema vuelve a la normalidad.
23 de junio, 19:31	La estabilidad tras la recuperación se mantiene.	Incidente resuelto: los sistemas están completamente normales; el equipo entra en el flujo de revisión posterior al incidente.

Conclusiones clave y evaluación de nuestra experiencia

Aunque el postmortem aguas arriba se centró en el ajuste de la base de datos y la infraestructura del clúster, nuestra evaluación interna se centra en la degradación elegante y la resiliencia arquitectónica.

1. El poder del "kill switch"

El momento decisivo de nuestra recuperación ocurrió a las 10:34 UTC. Cuando la región secundaria de nuestro proveedor se vino abajo, pasamos de intentar gestionar colas en segundo plano a implementar una derivación estructural.

• La derivación: al desplegar un cambio global de configuración para desactivar las tareas en segundo plano, cortamos de hecho la conexión con nuestra dependencia averiada. Esto obligó a que las transacciones críticas de usuario, como los correos de confirmación de reserva, evitaran temporalmente el motor congelado de fondo y se procesaran directamente.

• En 7 minutos, las funciones principales del negocio quedaron completamente restauradas para nuestros usuarios, lo que demuestra que contar con rutas de fallback integradas y activables para dependencias externas importantes es un requisito innegociable para una alta disponibilidad.

2. Gestionar trampas de concurrencia multirregión

Durante la fase de mitigación, navegar por una configuración multirregión presentó limitaciones de plataforma inesperadas. Las tareas atascadas en una fase intermedia en la región de EE. UU. siguieron consumiendo la capacidad global de ejecución de nuestra cuenta incluso después de que apuntáramos nuestra aplicación a Europa.

• Identificar y ejecutar una cancelación masiva dirigida del grupo bloqueado de EE. UU. a la 01:10 fue clave para liberar capacidad de ejecución en nuestra nueva región europea de destino.

3. Endurecimiento del radio de impacto aguas arriba

Aunque nuestra solución de emergencia salvó la situación en los flujos críticos para el negocio, como el correo electrónico, seguíamos teniendo más de 13,000+ tareas sentadas, inactivas, en colas congeladas aguas arriba hasta que el proveedor se recuperó por completo.

• El camino a seguir: de cara al futuro, estamos evaluando el diseño de un búfer más localizado. Para trabajos en segundo plano o webhooks salientes, estamos valorando implementar una cola interna ligera de preparación que pueda almacenar tareas localmente durante un apagón aguas arriba, garantizando el orden correcto durante la repetición.

Resumen

En última instancia, nuestro equipo de ingeniería diagnosticó con éxito una trampa de concurrencia multirregión compleja, desvió el tráfico y desplegó una derivación arquitectónica creativa que salvó la experiencia de nuestros usuarios horas antes de que nuestro proveedor lograra estabilizar su infraestructura.

Sabemos que este fue un momento muy difícil para el equipo de Trigger.dev. Les respetamos y seguimos teniendo una gran colaboración. Este post solo pretende compartir nuestra versión del incidente y cómo reaccionó nuestro equipo.