Um serviço de licenciamento falhou.

A partir daí, usuários do Xbox começaram a ter problemas para entrar na conta, visualizar a biblioteca e iniciar jogos. A indisponibilidade atravessou diferentes funcionalidades desde a noite de domingo até a segunda-feira, com a recuperação ocorrendo de forma desigual entre regiões.

Só que um detalhe chamou muito mais atenção do que a falha do serviço em si:

alguns jogos em mídia física também deixaram de iniciar.

A reação imediata foi previsível: se até um jogo em disco para quando um serviço remoto cai, então o console depende da internet para tudo.

Mas a explicação posterior da Microsoft tornou o incidente tecnicamente mais interessante.

Segundo Scott Van Vliet, CTO do Xbox, em declaração posterior ao The Verge, jogos em disco não deveriam ter sido bloqueados daquela forma. A Microsoft identificou um problema que impediu alguns consoles de utilizar corretamente os saved entitlements durante a indisponibilidade e afirmou que o modo offline também foi projetado para se apoiar nesses entitlements salvos.

Isso confirma que o Xbox possui mecanismos projetados para preservar acesso em determinados cenários offline, incluindo o uso de saved entitlements.

O que as informações públicas não permitem afirmar é que existia exatamente um fallback automático do fluxo online para o fluxo local, com a máquina de estados que desenharemos neste artigo. Essa parte será usada apenas como modelo arquitetural para explorar a lição do incidente.

Esse detalhe muda completamente a história.

Não é apenas um caso sobre “online versus offline”.

É um caso sobre uma pergunta muito mais importante para qualquer sistema distribuído:

Quando a sua dependência realmente cair, você consegue provar que o caminho de continuidade funciona?

O que aconteceu

Na noite de 26 de julho de 2026, um serviço de licenciamento do qual o ecossistema Xbox depende começou a apresentar falhas.

Segundo a explicação pública de Scott Van Vliet, CTO do Xbox, o problema atingiu cenários que dependiam de verificações de entitlement: a informação que determina se um usuário ou dispositivo possui direito de acessar determinado conteúdo.

Entre os impactos relatados estavam:

• alguns cenários de sign-in;
• enumeração da biblioteca;
• inicialização de jogos;
• operações de parceiros de publicação e Store que dependiam dos mesmos sistemas.

O monitoramento automático detectou os primeiros sinais da falha, o time de plantão declarou um major incident e começou a trabalhar na mitigação. Parte da recuperação envolveu deslocar tráfego para infraestrutura saudável, mas diferentes regiões se recuperaram em ritmos distintos.

A recuperação avançou ao longo da segunda-feira, de forma desigual entre regiões, até que os serviços fossem restaurados e o incidente considerado mitigado.

Até aqui, temos um incidente relativamente familiar:

dependência crítica
       ↓
      falha
       ↓
 múltiplas jornadas
       ↓
   blast radius
       ↓
mitigação / failover

O aspecto realmente interessante aparece quando observamos uma das jornadas atingidas: iniciar um jogo usando mídia física.

O detalhe que parece pequeno

Durante a indisponibilidade, usuários relataram problemas inclusive com jogos em disco.

O próprio status do Xbox chegou a reconhecer impacto sobre jogos digitais e físicos.

Depois do incidente, porém, a Microsoft esclareceu que aquele não era o comportamento esperado.

O Xbox possui mecanismos de licença relacionados a mídia física. A documentação pública do Microsoft Game Development Kit expõe, por exemplo, o atributo isDiscLicense na estrutura XStoreGameLicense.

Essa API não documenta o mecanismo de saved entitlements citado no incidente; ela apenas confirma que o modelo público de licenciamento do GDK distingue licenças associadas a disco.

A documentação de distribuição física também descreve cenários de full disc support nos quais o conteúdo necessário pode estar no disco para permitir uso offline.

Não conhecemos a implementação interna responsável pelo incidente e não devemos inferi-la a partir dessas APIs públicas.

Mas a informação divulgada pela própria Microsoft é suficiente para estabelecer o ponto principal: alguns consoles deveriam conseguir utilizar saved entitlements durante a indisponibilidade e não o fizeram corretamente.

Conceitualmente, podemos pensar no fluxo assim:

O desenho não representa a arquitetura interna do Xbox.

Ele representa uma propriedade que qualquer arquiteto reconhece:

um sistema pode possuir um caminho normal e mecanismos alternativos para operar quando uma dependência deixa de estar disponível.

No restante do artigo, vou usar fallback como uma abstração arquitetural para esse caminho alternativo. Isso não significa que a implementação interna do Xbox faça uma troca automática exatamente como o diagrama acima.

A premissa escondida não era “o serviço nunca vai cair”

Seria fácil escrever que o problema foi confiar demais no serviço de licenciamento.

Mas a existência de um modo offline mostra que o produto foi projetado para operar, ao menos em determinados cenários, sem acesso contínuo aos serviços online.

Conceitualmente, isso significa que parte do comportamento pode ser sustentada por estado previamente disponível no dispositivo:

serviço online indisponível
             ↓
algumas operações ainda podem continuar
             ↓
estado/evidência previamente disponível

A premissa escondida que vale investigar em qualquer arquitetura desse tipo é mais sutil:

“Quando a dependência não estiver disponível, o mecanismo de continuidade continuará funcionando.”

Essa é uma premissa comum em sistemas considerados resilientes.

Temos réplica para quando o banco principal cair.

Temos outra região para quando uma região cloud ficar indisponível.

Temos cache para quando a API externa falhar.

Temos sessão local para quando o provedor de identidade não responder.

Temos último estado conhecido para quando uma configuração remota não responder.

Temos um modo degradado para quando determinada capacidade estiver indisponível.

Cada um desses mecanismos pode estar perfeitamente desenhado no diagrama.

Isso ainda não prova que funciona.

Fallback é um caminho de produção

Existe uma assimetria perigosa entre o caminho normal e o caminho de contingência.

O caminho normal é exercitado constantemente:

request
request
request
request
request
...

O fallback, em condições saudáveis, quase nunca:

fallback
   ↑
última execução: ?

Enquanto ele permanece adormecido, o restante do sistema continua evoluindo.

Schemas mudam.

Tokens expiram.

Bibliotecas são atualizadas.

Permissões são alteradas.

Regras de negócio ganham novos estados.

Formato de caches evolui.

Configurações deixam de existir.

O caminho principal acompanha essas mudanças porque é exercitado o tempo inteiro.

O caminho de recuperação pode envelhecer silenciosamente.

O Google SRE Book faz um alerta análogo ao discutir graceful degradation: o caminho que quase nunca é usado tende a ser justamente o caminho sobre o qual existe menos experiência operacional. O livro recomenda exercitar regularmente esse tipo de modo degradado, em vez de esperar uma sobrecarga ou incidente real para descobrir como ele se comporta.

Essa é uma mudança importante de mentalidade:

Fallback não é código de emergência. É uma funcionalidade de produção com baixa frequência de uso.

Se é uma funcionalidade, precisa participar do mesmo ciclo de engenharia das demais:

design
  ↓
implementação
  ↓
testes
  ↓
deploy
  ↓
observabilidade
  ↓
evolução
  ↓
regressão

Static stability: continuar sem criar uma nova dependência no momento da falha

Existe um conceito da Amazon Builders’ Library que funciona como uma boa analogia arquitetural para este caso: static stability.

Não é uma explicação oficial da arquitetura do Xbox.

Na definição da AWS, um sistema estaticamente estável continua executando o que já funcionava mesmo quando uma dependência fica prejudicada. Ele pode deixar de receber atualizações, mas o funcionamento existente não passa a depender de ações adicionais daquela dependência justamente no momento da falha.

Um exemplo clássico é separar control plane de data plane: a impossibilidade temporária de criar ou alterar recursos não deveria necessariamente impedir recursos já existentes de continuar operando.

Conceitualmente:

dependência saudável
        ↓
receber/atualizar estado
        ↓
operação normal

Durante a falha:

dependência indisponível
        ↓
não consigo atualizar o estado
        ↓
estado já disponível continua sustentando
as operações que podem permanecer válidas

Esse conceito é diferente de graceful degradation.

• Static stability enfatiza manter o funcionamento existente sem depender de uma reação dinâmica para se recuperar.
• Graceful degradation aceita reduzir qualidade ou funcionalidade para preservar a parte mais importante do sistema.

Em uma arquitetura hipotética de entitlement, usar uma evidência previamente adquirida para manter uma operação já autorizada se aproxima da ideia de static stability. Bloquear novas aquisições, mas preservar o uso já autorizado, é uma política de degradação funcional.

Essa distinção é mais útil do que simplesmente adicionar retry.

Retry pressupõe:

“Eu ainda preciso daquela dependência; vou tentar novamente.”

Static stability nos força a perguntar:

“O que já possui estado suficiente para continuar funcionando sem uma nova decisão daquela dependência?”

Essa pergunta muda o desenho.

Nem toda operação deve continuar

Nesse ponto surge um trade-off importante.

Se um sistema não consegue consultar sua fonte de verdade de autorização, ele deve permitir ou negar a operação?

Uma regra universal seria perigosa.

Imagine três situações:

1. iniciar conteúdo previamente autorizado
2. comprar novo conteúdo
3. alterar propriedade/licença

A indisponibilidade da mesma capacidade pode exigir comportamentos diferentes.

Podemos modelar uma política de degradação:

Essa matriz é muito mais útil do que decidir genericamente entre fail-open e fail-closed.

O problema deixa de ser:

dependência caiu → permitir ou negar?

e vira:

dependência caiu
       ↓
qual operação?
       ↓
qual evidência ainda possuímos?
       ↓
qual risco de usar estado anterior?
       ↓
qual comportamento degradado é aceitável?

Estado local compra disponibilidade — e cria um problema de consistência

Uma resposta arquitetural possível parece simples:

“Mantenha evidência suficiente localmente para algumas decisões.”

Mas um estado local usado para autorização imediatamente cria novas perguntas.

Entitlement
├── quem emitiu?
├── quando foi emitido?
├── ainda é válido?
├── pode ser revogado?
├── pertence a qual usuário?
├── pertence a qual dispositivo?
├── qual versão da política?
└── por quanto tempo pode ser usado offline?

Uma representação hipotética poderia ser:

{
  "resourceId": "game-123",
  "subject": "user-456",
  "deviceId": "console-789",
  "status": "ACTIVE",
  "issuedAt": "2026-07-26T20:00:00Z",
  "expiresAt": "2026-08-02T20:00:00Z",
  "policyVersion": 7
}

Isso não representa o formato utilizado pelo Xbox.

É apenas um modelo para visualizar o problema.

Se aumentamos a validade desse estado local:

TTL maior
   ↓
mais autonomia durante indisponibilidade

mas também:

TTL maior
   ↓
maior janela usando informação potencialmente obsoleta

Se reduzimos o TTL, diminuímos a janela de inconsistência, mas voltamos a depender rapidamente do serviço remoto.

Não existe resposta universal.

Existe uma decisão entre disponibilidade, consistência, segurança e experiência do usuário.

O verdadeiro blast radius de uma dependência

Outro aspecto importante do incidente é que a falha de licenciamento não atingiu uma única tela.

Ela apareceu em diferentes capacidades.

De maneira conceitual:

Quando desenhamos arquitetura, frequentemente organizamos componentes por ownership:

Time A
Time B
Plataforma
Fornecedor

O runtime não se importa com essa organização.

Se a jornada é:

Produto
  ↓
Serviço A
  ↓
Serviço B
  ↓
Serviço compartilhado

todos fazem parte do mesmo caminho de disponibilidade para aquela ação.

Essa é uma distinção que incidentes deixam muito clara:

Organizational boundary ≠ system boundary.

Um serviço pode estar fora da sua squad, fora da sua conta cloud ou até fora da sua empresa.

Se sua jornada para quando ele para, ele faz parte da arquitetura do seu produto.

Alta disponibilidade do componente não elimina o ponto lógico de falha

Há outra armadilha.

Imagine que o serviço de licenciamento seja extremamente redundante:

Load Balancer
├── instance 1
├── instance 2
├── instance 3
└── instance 4

Agora distribuímos em várias zonas:

Region
├── AZ-A
│   ├── instance
│   └── instance
└── AZ-B
    ├── instance
    └── instance

Podemos ir além:

Region A
Region B
Region C

Isso reduz vários modos de falha de infraestrutura.

Mas se todas as jornadas continuam dependendo logicamente de:

"preciso obter uma resposta válida do Licensing"

o acoplamento funcional continua existindo.

Podemos ter muita redundância física e ainda possuir um ponto lógico de falha.

Por isso a pergunta de arquitetura não deve ser apenas:

Quantas instâncias temos?

Ela também precisa ser:

O que acontece com a jornada quando essa capacidade inteira deixa de responder?

Como eu abordaria o problema

Se estivesse desenhando um sistema com uma dependência remota de autorização que precisa permitir algum grau de autonomia durante falhas, eu começaria pela jornada e não pelo componente.

1. Definir o que precisa sobreviver

Não:

"Licensing precisa ter 99,99%."

Mas:

"Um usuário previamente autorizado deve conseguir continuar usando o recurso durante uma indisponibilidade temporária do Licensing."

A diferença é grande.

A primeira frase mede um serviço.

A segunda define uma propriedade do sistema.

2. Identificar a evidência mínima necessária

Se a fonte de verdade desaparecer temporariamente, o que já sabemos?

última autorização válida?
token verificável?
snapshot?
licença local?
configuração assinada?

Se não existe nenhuma evidência independente da dependência, talvez o sistema não possua realmente um modo degradado.

Ele possui apenas retry.

3. Definir explicitamente a política de degradação

Para cada operação:

continua
degrada
bloqueia

Por exemplo:

Essa tabela força a equipe a discutir o comportamento do produto, não apenas o comportamento das APIs.

4. Exercitar o cenário antes que ele seja real

Aqui está a parte que mais importa.

Crie uma hipótese:

Se o serviço de entitlement ficar indisponível, usuários com evidência local válida continuam conseguindo executar a jornada X.

Então quebre deliberadamente a dependência.

entitlement-service = unavailable

E observe.

Não apenas:

API A está UP?
API B está UP?
Banco está UP?

Mas:

usuário consegue concluir a jornada?

O teste pode acontecer em diferentes níveis:

• integração automatizada;
• ambiente de staging;
• game day;
• chaos engineering controlado;
• pequena parcela de produção, quando apropriado.

A técnica é menos importante que a hipótese.

O objetivo é transformar:

“achamos que o fallback funciona”

em:

“temos evidência recorrente de que ele funciona.”

Observabilidade: medir a capacidade, não apenas os componentes

Imagine um dashboard durante o incidente:

Licensing availability: 0%

É importante.

Mas ele não responde a pergunta de produto:

quantos usuários ainda conseguem iniciar aquilo que já estavam autorizados a usar?

Para um sistema desse tipo, poderíamos acompanhar:

remote_entitlement_success_rate

local_fallback_attempts

local_fallback_success_rate

degraded_operation_success_rate

fallback_rejection_by_reason

local_entitlement_age

Agora conseguimos identificar:

remote success ↓
fallback attempts ↑
fallback success estável

O sistema está degradado, mas resiliente.

Compare com:

remote success ↓
fallback attempts ↑
fallback success ↓

A dependência caiu e a estratégia de recuperação também.

Essa segunda situação é muito mais perigosa.

E ela pode passar despercebida se monitoramos somente infraestrutura.

Um checklist melhor para design reviews

Incidentes como esse sugerem algumas perguntas úteis antes de colocar um sistema crítico em produção:

[ ] Quais dependências estão no caminho crítico da jornada?

[ ] O que acontece se cada uma delas ficar 5 minutos indisponível?

[ ] E 1 hora?

[ ] Existe algum estado previamente conhecido que permita continuar?

[ ] Quais operações podem usar estado anterior?

[ ] Quais precisam obrigatoriamente bloquear?

[ ] O fallback depende de outra chamada remota?

[ ] Quando esse caminho alternativo foi executado pela última vez?

[ ] Temos métricas separando caminho normal e degradado?

[ ] Um teste automatizado consegue remover a dependência e provar a jornada?

Talvez a pergunta mais valiosa seja a mais simples:

Se desligarmos essa dependência agora, o que exatamente para?

Responder isso de cabeça costuma ser muito mais difícil do que parece.

O que esse caso ensina sobre construir software

A indisponibilidade do Xbox vai desaparecer do noticiário.

A lição é duradoura.

1. Dependências são definidas pelo runtime, não pelo organograma

Se sua jornada precisa dela, ela faz parte do seu sistema.

2. Redundância de infraestrutura não elimina dependência funcional

Multi-AZ e multi-region ajudam contra vários tipos de falha, mas não respondem sozinhos ao que fazer quando uma capacidade inteira não está disponível.

3. Estado local pode transformar indisponibilidade em degradação

Mas também introduz validade, revogação, segurança e consistência.

4. Fallback é uma funcionalidade

Precisa de ownership, testes, métricas e evolução.

5. O caminho raro precisa ser exercitado

Se ele só roda durante incidentes, o incidente será também seu primeiro teste real.

6. Disponibilidade deve ser pensada pela jornada

Componentes verdes não garantem uma experiência funcionando.

Da mesma forma, uma dependência vermelha não precisa obrigatoriamente significar uma jornada indisponível.

Conclusão

O detalhe mais interessante do incidente do Xbox não foi simplesmente que um jogo em disco deixou de funcionar quando um serviço remoto caiu.

Foi que, segundo a própria Microsoft, ele não deveria ter parado.

A Microsoft afirmou que o modo offline foi projetado para se apoiar em saved entitlements. Durante a indisponibilidade, parte dos consoles não conseguiu utilizá-los corretamente.

Isso transforma um incidente de licenciamento em uma ótima provocação sobre resiliência.

Como princípio geral, podemos desenhar:

primary
  ↓
fallback

Podemos colocar uma segunda região.

Podemos armazenar cache.

Podemos criar circuit breakers.

Podemos adicionar retries.

Podemos escrever no documento de arquitetura que existe um modo degradado.

Nada disso, isoladamente, prova resiliência.

A prova aparece quando removemos uma dependência e o sistema continua entregando a função que prometemos manter.

Desenhar um fallback é uma decisão de design. Provar que o caminho de continuidade funciona sob falha é uma propriedade do sistema.

E essa propriedade precisa ser testada.

Antes que o próximo incidente faça o teste por você.

Referências verificadas nesta revisão

Incidente

1. Scott Van Vliet, CTO do Xbox — relato público do incidente — fonte primária para a dependência de licensing, impactos em sign-in/entitlements, declaração de major incident, deslocamento de tráfego e recuperação desigual.
2. The Verge — Xbox outage shouldn’t have affected games on disc, Microsoft confirms — fonte essencial e direta para a declaração posterior de Van Vliet de que jogos em disco não deveriam ter sido bloqueados, para o problema no uso de saved entitlements e para o comportamento esperado do modo offline.
3. The Verge — Xbox’s huge outage even blocked games on disc — cobertura do impacto em jogos digitais e físicos durante a indisponibilidade.
4. Tom’s Hardware — cobertura complementar do incidente — usada apenas como fonte complementar; interpretações arquiteturais próprias da publicação não são tratadas como confirmação da Microsoft.

Documentação técnica

1. Microsoft Learn / GDK — XStoreGameLicense — inclui o campo isDiscLicense.
2. Microsoft Learn / GDK — Creating discs — descreve full disc support e cenários de disponibilidade offline.

Referências arquiteturais

1. Amazon Builders’ Library — Static stability using Availability Zones.
2. Google SRE Book — Addressing Cascading Failures — especialmente a discussão sobre graceful degradation e a necessidade de exercitar caminhos raramente utilizados.