Depois de um incidente de nuvem, a pergunta útil não é qual provedor venceu, mas quais dependências estavam no caminho, que evidência existe e o que deve mudar. Esta revisão mantém apenas fatos apoiados pelo registro do provedor e pela arquitetura atual.
Linha do tempo do provedor
A AWS documenta que o evento em us-east-1 durou de 23:48 PDT de 19 de outubro a 14:20 PDT de 20 de outubro, com períodos de erros no DynamoDB, falhas de lançamento e conectividade EC2 e erros em alguns Network Load Balancers. Leia o resumo oficial da AWS.
A conclusão sustentada
O runtime principal do ShortURL.bot é documentado no Microsoft Azure, não na AWS; não foi uma queda direta do host principal. Isso não prova que toda requisição, integração ou destino de cliente ficou disponível, pois cada serviço upstream tem dependências próprias.
A arquitetura documentada
O backend usa Node.js Azure Functions, Azure Front Door na borda, MSSQL como armazenamento principal e Blob Storage; Cosmos permanece em caminhos legados. Não há base para dez regiões ativas, failover intercontinental em segundos ou Cosmos como camada principal.
Lições operacionais
- Monitore a jornada: o redirecionamento pode estar saudável e o destino não.
- Guarde o registro: status datado e atualização pública valem mais que marketing posterior.
- Teste recuperação: DNS, redirecionamento, identidade, armazenamento e destino separadamente.
Confira a evidência atual
Para saúde de componentes e histórico publicado, consulte a página de status do ShortURL.bot.