Graceful Degradation

Mantém a resposta de pé quando parte das dependências falha: cada serviço é classificado como core ou opcional, todos são chamados em paralelo com timeout próprio, e a resposta sai com o que respondeu e um tier que diz o quanto ela está reduzida. Use em telas e APIs que agregam fontes independentes.

passos: 6
arquivos: 6
testes: 0
tecnologias: 4

Lógica puraTypeScriptBunElysiaStryker

Cenário Relações Comparar

Baixar cartão

Cenário

O app do banco abre no painel da conta: saldo, nome do cliente e ofertas. O saldo é o motivo de abrir o app — o serviço de contas é core; nome e ofertas são opcionais. Com ofertas fora, o painel sai sem ofertas; com o cadastro lento, ele é cortado em 300 ms e o painel não espera; com o serviço de contas fora, o painel sai em modo só leitura, com transferência desligada.

Planta

Fluxo

10/10

10 passos — reproduza para seguir o fluxo

chamada
resposta ou assíncrono
falha
passo
toque num nó para focar
Outras plantas de fluxo

Como funciona

6 passos

Perde recursos, não perde o serviço.

Esconde cada passo: lembre antes de tocar para revelar.

Vocabulário compartilhado

AbortSignal.timeout+4

Promise.allSettled+2

rejected+1

Adapter

transfer+1

Graceful Degradation

X-Service-Tier+1

Graceful Degradation

01
SERVICES documenta quem é core e quem é opcional, e o timeout de cada um
02
dashboardBuild chama os três com Promise.allSettled e AbortSignal.timeout individual — nenhuma falha derruba a resposta
03
Cada serviço rejected vira um warning (offers_unavailable) e uma seção ausente, nunca um valor inventado
04
tierClassify: nenhuma falha é FULL; só opcional, DEGRADED; qualquer core, MINIMAL
05
capabilitiesFor desliga transfer e statement em MINIMAL — sem saldo não há como validar a transferência
06
A API responde 200 com o tier em X-Service-Tier e loga dashboard.degraded em toda resposta reduzida

Trade-offs

O que se ganha, o que se paga

3 vantagenscada ganho tem um preço3 custos

Vantagens

A falha de um serviço opcional não derruba a tela
Timeout por serviço limita a latência ao core
Tier e log tornam a degradação visível para ops

Custos

O cliente vê uma tela incompleta e a UI precisa tratar cada ausência
Timeout curto demais corta respostas que chegariam
A lista core × opcional precisa ser mantida quando surge serviço novo

apps/resiliency/graceful-degradation

6 arquivos

src/

tier_service.tsLista core × opcional, timeouts, classificação do tier e capacidades
dashboard_account.tsChamada paralela com timeout individual e montagem da resposta parcial
api_dashboard.tsEndpoint com X-Service-Tier e log da degradação
upstream_bank.tsServiços de contas, cadastro e ofertas em ElysiaJS com saúde trocada em runtime
config_degradation.tsConfiguração validada do ambiente
demo.tsdemoPainel com ofertas fora, cadastro lento e contas fora