Degradação graciosa

1) A essência da abordagem

A degradação grátis é uma transição controlada do sistema para um modo mais simples, mas útil, com recursos escassos, falhas de dependência ou picos de carga. O objetivo é preservar o núcleo de valor para o usuário e a sustentabilidade da plataforma, sacrificando a capacidade e a qualidade secundárias.

• Previsibilidade: cenários pré-definidos e «escadas» de degradação.
• A limitação do raio de impacto é o isolamento de fichas e dependências.
• Observabilidade: métricas, logs e traçáveis «que nível de degradação é ativo e porquê».
• Reversível: retorno rápido à normalidade.

2) Princípios e limites

1. Salvar o principal: seu SLA/SLO básico (por exemplo, «compra», «login», «pesquisa») é a prioridade acima dos secundários (avatares, recomendações, animações).

• Segurança, pagamentos, direitos - fail-closed (melhor renúncia do que violação).
• Conteúdo, dicas, avatares - fail-open com folback.
• 3. Orçamentos temporários: temporizações de cima para baixo (cliente
• 4. Controle de custo: a degradação deve reduzir o consumo de CPU/IO/rede, não apenas «esconder» erros.

3) Níveis de degradação

3. 1 Cliente/UX

Skeletons/playsholders e «preguiçosa» subcontratação de widgets secundários.
Partial UI: Os blocos críticos são carregados, os blocos secundários escondidos/simplificados.
A caixa no lado do cliente é last-known-good (LKG) com a marca «os dados podem ter ficado obsoletos».
Modo offline: fila de comandos com repetição mais tarde (idempotidade!).

3. 2 Edge/CDN/WAF/API

stale-while-revalidate: dê-lo, atualizamos o fundo.
Rate limiting & load shedding: Ao sobrecarregar, reiniciamos o tráfego de fundo/anónimo.
Geofence/routing ponderado: o tráfego é levado para a região mais próxima e saudável.

3. 3 Camada de serviço

Partial response: Devolva parte dos dados + 'warnings'.
Modo read-only: proibição temporária de mutações (bandeiras).
Brownout: desativação temporária de fichas intensivas (recomendações, enriquecimento).
Adaptativa concurrency: reduzindo dinamicamente o paralelismo.

3. 4 Dados/estiagem

Cash como fonte de verdade com TTL (temporariamente): «Melhor aproximadamente do que nenhum».
Menos precisão de modelos/algoritmos (fast path vs accurate path).
Defer/queue: transferência de tarefas pesadas para fundo (outbox/job queue).
As filas prioritárias são eventos críticos em uma sala de aula separada.

4) «Escadas» degradação (playbooks)

• L0 (normal) → L1: ocultar a personalização e os banners → L2: desativar sinônimos/phaszi-busca → L3: limitar o tamanho da resposta e o tempo de espera de até 300 ms → L4 - dar resultados de 5 min → L5: «read-only & cached only» + fila de pedidos de cruzamento.

• Triggers: CPU sobrecarregado> 85% p95> destino, erros> limiar, Kafka> limiar, flap de dependências.
• Ações: incluir a bandeira X, reduzir a concurrency para N, mudar a origem Y para kesh.
• Os critérios de saída são 10 minutos de métricas verdes, provisão de recursos.

5) Políticas decisórias

5. 1 Orçamento errado e SLO

Use o error-budget burn rate como desencadear brownout/shedding.
Política: «Se burn-rate> 4 x por 15 min - incluir L2 degradação».

5. 2 Admission control

Limitamos o RPS de entrada em vias críticas para garantir o p99 e evitar o colapso das filas.

5. 3 Priorização

Classes: interativa> system> background.
Prioridades para o tenante (Gold/Silver/Bronze) e justiça (fair share).

6) Pattern e implementação

6. 1 Load shedding (servidor)

Retire os pedidos antes que eles emprestem todos os recursos.
Devolva «429 »/« 503» com «Retry-After» e explica a política (para clientes).

Envoy (adaptive concurrency + circuit breaking)

yaml typed_extension_protocol_options:
envoy. filters. http. adaptive_concurrency:
"@type": type. googleapis. com/envoy. extensions. filters. http. adaptive_concurrency. v3. AdaptiveConcurrency gradient_controller_config:
sample_aggregate_percentile: 90 circuit_breakers:
thresholds:
- max_requests: 2000 max_pending_requests: 500 max_connections: 1000

6. 2 Brownout (simplificação temporária)

A ideia é reduzir o «brilho» (custo) do fic quando os recursos estiverem fora.

kotlin class Brownout(val level: Int) { // 0..3 fun recommendationsEnabled() = level < 2 fun imagesQuality() = if (level >= 2) "low" else "high"
fun timeoutMs() = if (level >= 1) 150 else 300
}

6. 3 Partial response e avisos

json
{
"items": [...],
"degradation": {
"level": 2,
"applied": ["cache_only", "no_personalization"],
"expiresAt": "2025-10-31T14:20:00Z"
}
}

6. 4 Stale-while-revalidate na borda (Nginx)

nginx proxy_cache_valid 200 10m;
proxy_cache_use_stale error timeout http_500 http_502 http_504 updating;
proxy_cache_background_update on;

6. 5 Alternador read-only (Kubernetes + bandeira)

yaml apiVersion: v1 kind: ConfigMap data:
MODE: "read_only"

The code should check MODE and block mutations with a friendly message.

6. 6 Kafka: backpressure e classes de fila

Alterne os heavy-consumers para menor 'max. poll. records ', limite a produção de batch-e.
Divida os eventos «críticos» e «bulk» por tópicos/quotas.

6. 7 UI: graceful fallback

Esconda os widgets «pesados», mostre kesh/esqueleton e marca claramente os dados obsoletos.

7) Exemplos de configuração

7. 1 Istio: outler + pula prioridade

yaml outlierDetection:
consecutive5xx: 5 interval: 10s baseEjectionTime: 30s maxEjectionPercent: 50

7. 2 Nginx: tráfego de fundo debaixo da faca primeiro

nginx map $http_x_priority $bucket { default low; high high; }

limit_req_zone $binary_remote_addr zone=perip:10m rate=20r/s;
limit_req_status 429;

server {
location /api/critical/ { limit_req zone=perip burst=40 nodelay; }
location /api/background/ {
limit_req zone = perip burst = 5 nodelay; # stricter
}
}

7. 3 Feature flags / kill-switches

Guarde em configuração dinâmica (ConfigMap/Consul) e atualize sem lançamento.
Separe o per-fic e as bandeiras globais, para logar a ativação.

8) Observabilidade

8. 1 Métricas

'degradation _ level <service 03' é o nível atual.
'shed _ requests _ total\road, reason 03' - quanto foi descartado e porquê.
'stale _ responses _ total' - Quantos kesha foram emitidos.
`read_only_mode_seconds_total`.
`brownout_activations_total{feature}`.
Orçamento errado: burn-rate, proporção de violações SLO.

8. 2 Training

Os atributos dos spans são 'degraded = true', 'level = 2', 'reason = upstream _ timeout'.
Links entre retais/pedidos hedged para ver a contribuição para as caudas.

8. 3 Logs/alerts

Eventos de alteração de níveis de degradação com as causas e o dono da mudança.
Alertas de nível «adoçante» (degradação há muito tempo).

9) Gerenciamento de riscos e segurança

Não degrade a autenticação/autorização/integridade de dados: melhor falha.
A camuflagem PII é preservada em qualquer modo.
Finanças/pagamentos: apenas operações idumpotentes, tempo rigoroso e reembolsos; em dúvida - read-only/hold.

10) Anti-pattern

Degradação silenciosa sem dica ao usuário e sem telemetria.
Tempestades retraí em vez de load shedding e breves temporais.
«Cortadores» globais sem segmentação é um enorme blast radius.
Misture os caminhos prod e facilitados em um único cachê/fila.
Eterna degradação, brownout como «nova norma», critérios de saída esquecidos.
Stale-write: tentar gravar com base em dados obsoletos.

11) Folha de cheque de implementação

• O núcleo de valor e os cenários críticos do usuário foram definidos.
• As escadas de degradação são elaboradas por serviços/domicílios com desencadeadores e saídas.
• Os temporizadores/restrições foram introduzidos e o server-side load shedding.
• Os rate limits e as classes prioritárias de tráfego foram configurados.
• Implementados partial response, read-only, stale-while-revalidate.
• Funções flags/kill-switches integradas com áudio.
• Métricas/trailing/alertas para níveis de degradação e causas.
• Exercício de game day regular com simulação de sobrecarga/falha.
• São documentados o SLO e a política de erro-boodget → degradação.

12) FAQ

Q: Quando escolher brownout e quando escolher shedding?
A: Se o objetivo é reduzir o custo das solicitações sem rejeição - brownout. Se o objetivo é proteger o sistema, quando nem a simplificação ajuda - shedding logon.

Q: Informar o usuário sobre a degradação?
A: Para os cenários críticos, sim (crachá «modo limitado»). A transparência reduz o apoio e o descontentamento.

O dinheiro pode ser a fonte da verdade?
A: Temporariamente, sim, com SLA explícito e marcas de obsolescência. Para mutações, proibido.

Como não «quebrados» para fazer retraias?
A: Temporizações curtas, backoff exponencial com jitter, idempotação e limite de tentativas; retraite apenas operações seguras.

13) Resultado

A degradação graciosa é um contrato arquitetônico e um conjunto de regimes de funcionamento administrados que são incluídos através de métricas e orçamento errado. Escadas bem projetadas, timeouts rigorosos e shedding, kesh folbacks e brownout, além de observabilidade poderosa - e sua plataforma permanece útil e econômica mesmo em uma tempestade.