Resumo

  • A Cloudflare abriu o incidente às 06:59 UTC de 19 de agosto, informou uma correção às 07:06 e declarou a resolução às 07:20. O aviso mencionou possíveis erros de sobrecarga para vários clientes de Hong Kong.
  • O histórico rebaixou apenas o “Durable Objects”. O local de Hong Kong, o RealtimeKit e o Realtime SFU continuaram como operacionais, embora o texto dissesse que usuários desses produtos dependentes também poderiam encontrar erros.

O painel registrou duas verdades ao mesmo tempo. O local HKG estava operacional. O “Durable Objects”, serviço que mantém estado e coordena operações, estava com desempenho degradado.

O registro oficial começou às 06:59:19 UTC de 19 de agosto. A Cloudflare disse investigar um problema com potencial de atingir vários clientes de Hong Kong e elevar os erros de sobrecarga ao usar “Durable Objects”, RealtimeKit e Realtime SFU. Às 07:06:33, uma correção havia sido implantada. Às 07:20:23, o incidente foi encerrado.

A janela registrada foi de aproximadamente 21 minutos e recebeu impacto minor. Não houve divulgação de causa raiz, conteúdo da correção, quantidade de clientes, taxa de erro, namespaces ou objetos atingidos. O aviso também não estabeleceu perda de dados, queda de reuniões ou indisponibilidade geral de Hong Kong.

A diferença entre os componentes ajuda a localizar a falha. “Durable Objects” mudou de operational para degraded_performance. HKG, RealtimeKit e Realtime SFU permaneceram operational nos mesmos dados. Ainda assim, a atualização inicial alertou que usuários dos produtos Realtime poderiam encontrar sobrecarga. O verde representava um perímetro amplo; não comprovava cada operação dependente de estado.

Segundo a documentação da Cloudflare, cada “Durable Object” combina computação com armazenamento privado, transacional e fortemente consistente. O objeto tem nome globalmente único e serve como ponto de coordenação para clientes que compartilham estado, como participantes de uma sala, conexões WebSocket ou operações sobre um mesmo contador.

Um objeto individual executa em um local e em uma única thread. A plataforma distribui muitos objetos pela rede, mas a identidade que contém um estado específico não equivale a uma requisição sem estado que pode pousar em qualquer borda disponível. Se esse caminho de coordenação devolve sobrecarga, o restante do local pode continuar acessível sem que a ação da aplicação termine.

Também não é correto transformar “sobrecarga” em diagnóstico. O guia de solução de problemas enumera filas com requisições demais, dados demais na fila, espera excessiva e muitas chamadas para o mesmo objeto em uma janela curta. O incidente de Hong Kong não identifica uma dessas variantes. Tampouco atribui a ocorrência ao tráfego ou ao modelo de objetos de um cliente.

Há, porém, uma defesa documentada. No tratamento de erros, a Cloudflare orienta que exceções marcadas .overloaded não sejam repetidas imediatamente, pois a nova carga piora a sobrecarga e a taxa de falhas. Essa é uma regra geral, não prova de que todas as respostas do incidente tinham essa marca. A aplicação deve reconhecer o erro e escolher entre espera progressiva, recusa controlada ou modo limitado.

O aviso sobre Realtime exige a mesma cautela. A Cloudflare descreve o RealtimeKit como SDKs e APIs para voz e vídeo ao vivo sobre o Realtime SFU, que encaminha áudio e vídeo. Nada no registro revela se houve falha na criação de reuniões, presença, sinalização, gestão de faixas ou transporte de mídia. Não há base para afirmar que chamadas foram encerradas.

A lacuna pode ser investigada com telemetria do cliente. O “Durable Objects” oferece métricas por namespace e requisição, com filtros para nome ou ID de um objeto. Alinhar erros, latência e falhas de negócio ao período 06:59–07:20 permite distinguir um problema amplo de concentração em poucas unidades lógicas.

O incidente não deve ser ligado à manutenção de interconexão HKG prevista para mais tarde naquele dia. As fontes congeladas não publicam nexo causal. Cidade e data iguais não demonstram equipamento, instalação, circuito ou alteração em comum.

A recuperação rápida limitou o intervalo observado, mas não resolveu a decisão do cliente: o que fazer quando o ponto de estado consistente não responde? Distribuir unidades por mais objetos, limitar retentativas, tornar operações idempotentes ou suspender temporariamente uma função são respostas possíveis. Todas exigem saber qual garantia pode ser relaxada.

Uma análise posterior da Cloudflare, com modo de sobrecarga, fronteira afetada e reparo, seria o próximo fato relevante. Até lá, o relato precisa manter a escala: um produto regional com estado degradou por 21 minutos sob um local que continuou verde.

Fontes