Radar Tech: Quay.io entrou em read-only e travou os pushes — a lição de arquitetura sobre separar write-path de read-path

A notícia que dominou as conversas de infraestrutura nas últimas 24 horas é pequena em manchete e enorme em consequência: o Quay.io, registry de containers da Red Hat, entrou em modo somente-leitura. Durante cerca de 15 horas, publicar uma imagem nova foi impossível. Servir as imagens que já existiam, não.

O que aconteceu, segundo as fontes

A página oficial de status da Red Hat registra o incidente como "Initial: Quay.io Push/Pull Degraded", aberto em 14 de setembro de 2026, às 13:34 UTC. A causa reportada foi corrupção em tabelas do banco de metadados do serviço.

A cronologia, direto dos updates oficiais, é reveladora:

• 00:39 UTC (15/set) — "2 de 3 tabelas afetadas foram atualizadas. A última está rodando. Quay.io permanece em modo somente-leitura. Image pulls continuam funcionando, mas pushes e outras operações de escrita estão temporariamente indisponíveis."
• 02:49 UTC — tabelas atualizadas, ainda restaurando o tráfego de leitura/escrita completo.
• 04:05 UTC — "A correção foi implantada. Quay.io está servindo requisições de leitura/escrita. Seguimos monitorando."
• 04:31 UTC — "Push e pull funcionando normalmente. Continuamos monitorando a saúde do serviço. O scan de vulnerabilidades Clair está temporariamente desabilitado."

No mesmo painel da Red Hat apareceu, no mesmo intervalo, uma parcial indisponibilidade do catalog.redhat.com e um registro de "AWS Outage: me-central" — três sinais de que o dia foi de degradação em camadas, não de um evento isolado.

O detalhe que quase todo mundo pula

O detalhe mais importante está em uma frase que passa batido: pushes pararam, pulls continuaram.

Isso não é sorte — é arquitetura. Um registry de artefatos tem dois caminhos com SLOs diferentes:

• o write-path (push): autenticação → autorização → validação → gravação de metadados → gravação de blob;
• o read-path (pull): resolução de manifest → leitura de blob → entrega.

Quando o banco de metadados adoece, faz sentido do ponto de vista de integridade fechar a escrita e preservar a leitura. O provedor escolheu fail-closed: melhor recusar o artefato novo do que gravar metadado inconsistente.

E por que o mundo não parou? Por dois mecanismos que já estavam no lugar:

1. Digests são imutáveis. Se o manifesto de produção aponta para sha256:... e não para uma tag mutável, o conteúdo é verificável independentemente do que o registry faz no write-path.
2. Cache de nó. O kubelet já tem a imagem no disco. Subir um pod existente ou reiniciar um container não toca o registry.

Traduzindo: o pull funcionou para quem já tinha o artefato. A dor ficou inteira no plano de build — CI travado, promoções congeladas, releases atrasadas — e quase nula no plano de execução.

As perguntas de arquitetura que sobram

Se você opera um registry (Quay, Harbor, Artifactory, ECR, GAR) ou depende de um, o incidente deixa perguntas concretas:

• Qual é o seu tempo até o impacto? Se o push parar agora, quantos minutos até um release crítico travar?
• Você sabe separar os dois planos? Sabe dizer, hoje, o que continua funcionando quando o write-path morre?
• Seus manifestos usam digest ou tag mutável? Se for tag, você acabou de perder a imutabilidade junto com o registry.
• Existe um caminho de contingência de primeira classe? Publicar num registry secundário é plano de emergência ou improviso?
• Se houve corrupção de metadados, você confia no que foi publicado na janela? Verificar integridade retroativa não é paranoia — é o único jeito de saber.
• E o scan desabilitado? Quando o Clair sai do ar, o que acontece com a sua política de admissão? Ela continua exigindo assinatura e SBOM, ou alguém "destrava" o deploy?

A tentação perigosa

Todo incidente de registry traz a mesma pressão: alguém vai pedir para desabilitar a verificação de assinatura "só durante a crise". É exatamente o erro que transforma um problema de disponibilidade em um incidente de segurança. Degradação de disponibilidade não pode produzir degradação de segurança — a política de admissão, o RBAC, o SBOM e a assinatura precisam sobreviver ao modo degradado, porque é justamente quando ninguém está olhando que uma janela explorável vale mais.

O caminho correto não é afrouxar: é espelhar, reduzir escopo e reconciliar depois. Publicar no registry secundário pelo mesmo digest, drenar a fila de builds quando o write-path voltar e reapontar tags divergentes para o digest assinado canônico.

O que dá para fazer esta semana

• Congele promoções automaticamente quando a taxa de erro de push passar de um limiar — não dependa de alguém perceber.
• Meça o pull como SLO separado do push. Eles falham por motivos diferentes e merecem orçamentos de erro diferentes.
• Torne a assinatura um invariante não degradável. Nenhuma exceção, nem em incidente.
• Escreva o runbook do modo degradado com critério de saída binário ("só retome promoções quando 100% das tags apontarem para o mesmo digest, por 30 min").
• Planeje a verificação retroativa para qualquer evento de corrupção de metadados: recalcule digests e revalide assinaturas de tudo que foi publicado na janela afetada.

Resumo do dia, em uma linha

O Quay.io ficou 15 horas sem aceitar imagem nova por corrupção de metadados, e o mundo não parou — porque pull e push são caminhos diferentes, e porque digests não mentem. Quem confunde os dois planos descobre a diferença no pior momento possível.

Este post acompanha o prompt "Resiliência de Registry de Artefatos — Write-Path Degradado" no catálogo da ArchPrompts: um pacote de 6 arquivos (prompt, guardrails, exemplos, harness de verificação, templates e runbook) para levar um LLM a projetar exatamente essa contingência — com gatilhos numéricos, ADRs prontos e a invariante de que a contingência nunca afrouxa a assinatura.

Fontes: página oficial de status da Red Hat (incidente "Initial: Quay.io Push/Pull Degraded", 14–15/set/2026) e a discussão do item no Hacker News (14/set/2026, 22:56 UTC).