Quando uma dependência derrete: o nosso post-mortem do incidente de 22–23 de junho

A linha temporal alinhada

Hora (UTC)	O que aconteceu a montante (Relatório completo)	O que aconteceu internamente / A nossa experiência
22 de junho, 19:00	O gatilho: a falta de capacidade na AWS em us-east-1 faz com que ~10,000 execuções se acumulem nas filas a montante.	As nossas tarefas em segundo plano começam silenciosamente a ficar presas. As filas começam a crescer por baixo da superfície.
22 de junho, 20:09	O colapso: o plano de controlo do Kubernetes a montante atinge 100% de CPU, perde o quorum da base de dados e **us-east-1** fica completamente em baixo.	O nosso ambiente de produção deixa de processar execuções. Milhares de tarefas em toda a plataforma ficam bloqueadas na fila.
22 de junho, 21:58	A engenharia a montante está ativamente a combater um ciclo de "tempestade de reconexão".	Incidente reportado: são detetadas taxas elevadas de falha e é ativada uma sala interna de incidente.
23 de junho, 00:59	O fornecedor a montante recomenda que os utilizadores mudem manualmente as cargas de trabalho para a região eu-central-1.	Responsável pelo incidente atribuído: a sala de resposta ao incidente é totalmente ativada com um responsável designado para tratar da avaliação entre regiões.
23 de junho, 01:01 - 02:10	O fornecedor a montante implementa uma atualização de emergência do painel para permitir mover execuções em massa entre regiões.	Mitigação ativa: às 01:10, a equipa cancela manualmente as nossas execuções em fila nos EUA para libertar a capacidade de execução bloqueada da nossa conta e encaminha todo o novo tráfego para a região europeia. Às 02:10, as mensagens voltam a ser processadas.
23 de junho, 02:02 - 02:33	O fornecedor a montante está a aumentar manualmente o armazenamento de apoio da sua base de dados.	Gravidade elevada para crítica: mais de 30,000+ das nossas próprias tarefas estão agora em fila à espera. A equipa publica uma atualização de estado crítica na nossa página pública de estado.
23 de junho, 04:35 - 05:05	As atualizações da infraestrutura a montante abrandam novamente a execução até quase parar.	O estrangulamento dos webhooks: as taxas de processamento caem. Às 05:05, identificamos que a nossa fila de entrega de webhooks é o principal estrangulamento que se recusa a esvaziar.
23 de junho, 08:38	A segunda cascata: o tráfego global redirecionado sobrecarrega a região europeia do fornecedor, derrubando-a completamente.	Paragem total: as duas regiões a montante estão agora, na prática, mortas. Temos mais de 13,000+ tarefas congeladas em trânsito, totalmente à mercê da recuperação a montante.
23 de junho, 10:34	A engenharia a montante está com dificuldades para pôr novamente online a região europeia.	Implementação do disjuntor: ao perceber que a camada principal de processamento em segundo plano está completamente bloqueada, a nossa equipa passa da mitigação de infraestrutura para um desvio arquitetural. Implementamos um hotfix de emergência em todos os ambientes principais da aplicação e da API para desativar temporariamente a gestão de tarefas assíncronas.
23 de junho, 10:41	O fornecedor a montante continua a trabalhar no redimensionamento dos nós do plano de controlo.	Alívio imediato: o desvio arquitetural funciona na perfeição. Ao contornar as filas congeladas em segundo plano, os processos críticos da aplicação recorrem a caminhos de execução direta. A engenharia confirma: "Os emails estão a fluir novamente."
23 de junho, 17:06	O fornecedor a montante finalmente estabiliza as duas regiões e repõe a velocidade de processamento.	Fila limpa: a engenharia confirma que as nossas filas em ambas as regiões ficaram completamente vazias. O desempenho do sistema volta ao normal.
23 de junho, 19:31	A estabilidade após a recuperação mantém-se.	Incidente resolvido: os sistemas estão totalmente normais; a equipa entra no fluxo de revisão pós-incidente.

Principais conclusões e a nossa avaliação da experiência

Embora o post-mortem a montante se tenha focado no ajuste da base de dados e na infraestrutura do cluster, a nossa avaliação interna foca-se na degradação graciosa e na resiliência arquitetural.

1. O poder do "kill switch"

O momento decisivo da nossa recuperação aconteceu às 10:34 UTC. Quando a região secundária do nosso fornecedor colapsou, deixámos de tentar gerir filas em segundo plano e passámos a implementar um desvio estrutural.

• O desvio: ao implementar uma alteração global de configuração para desativar as tarefas em segundo plano, cortámos efetivamente a ligação à nossa dependência avariada. Isso obrigou transações críticas dos utilizadores, como emails de confirmação de reservas, a contornar temporariamente o motor em segundo plano congelado e a serem processadas diretamente.

• Em 7 minutos, as funções principais do negócio foram totalmente restauradas para os nossos utilizadores, provando que ter caminhos de fallback integrados e ativáveis para grandes dependências de terceiros é um requisito inegociável para alta disponibilidade.

2. Gerir armadilhas de concorrência multirregião

Durante a fase de mitigação, navegar numa configuração multirregião apresentou limitações inesperadas da plataforma. Tarefas presas numa fase intermédia na região dos EUA continuaram a consumir a capacidade global de execução da nossa conta, mesmo depois de apontarmos a aplicação para a Europa.

• Identificar e executar um cancelamento em massa direcionado do conjunto preso dos EUA às 01:10 foi fundamental para libertar capacidade de execução na nossa nova região-alvo europeia.

3. Endurecimento do raio de impacto a montante

Embora o nosso fallback de emergência tenha salvado o dia para fluxos críticos como email, continuámos com mais de 13,000+ tarefas sentadas, sem avançar, em filas congeladas a montante até o fornecedor recuperar totalmente.

• O caminho futuro: daqui para a frente, estamos a avaliar a criação de um buffer mais local. Para jobs em segundo plano ou webhooks de saída, estamos a avaliar a implementação de uma fila interna de staging ligeira que possa armazenar tarefas localmente durante um apagão a montante, garantindo a ordem correta durante a reprodução.

Resumo

No fim de contas, a nossa equipa de engenharia diagnosticou com sucesso uma armadilha complexa de concorrência multirregião, desviou o tráfego e implementou um desvio arquitetural criativo que salvou a experiência dos nossos utilizadores horas antes de o nosso fornecedor conseguir estabilizar a infraestrutura.

Sabemos que este foi um momento muito difícil para a equipa da Trigger.dev. Respeitamo-los e continuamos a ter uma excelente parceria. Este post serve apenas para partilhar o nosso lado do incidente e como a nossa equipa reagiu.