Operações e Gerenciamento → Dependências de Serviços

Dependências de serviços

1) Por que é necessário

Qualquer plataforma de produção é um gráfico: usuários do → Edge/API → serviços de domínio → filas/striam → BD/cachês → provedores externos (pagamentos, KYC, provedores de jogos). Um erro em uma costela de grafo é frequentemente «caminhado» por toda a rede, com atrasos crescentes, retais, filas engarrafadas, falhas em cascata. O gerenciamento de dependências reduz o raio explosivo e torna os lançamentos previsíveis.

• Ver um gráfico completo de chamadas e saber quem depende de quem.
• Prevenir falhas em cascata e «tempestade de retrações».
• Programar lançamentos com compatibilidade e divulgação SLO.
• Aumentar MTTR: mais rápido para encontrar o verdadeiro nó de origem (root causa).

2) Tipos de dependências

Sincronizados (RPC: REST/gRPC/GraphQL): conectividade rígida por latência/disponibilidade. Precisamos de temporizadores, breakers, orçamento de retrações.
Asinhrones (Event/Stream: Kafka/Rabbit/Pulsar): conectividade mais sustentável, mas há uma lag/backlog e semântica de entrega (at-least-once, idempotency).
Armazenamento (DB/Cachê/Object store): recursos compartilhados → contêineres, limites de conectórios/IOPS, evision, replicação.
Provedores externos (PSP/KYC/games): quotas, chamadas pagas, janelas de serviço, SLA legal.
Operacionais (lançamentos, fichiflags, configs): dependências indiretas através de configurações, segredos, schema registry.

3) Catálogo de serviços e gráfico de dependências

• Proprietários (Squad/chat/On-call rota), repo, ambiente, artefatos.
• Contratos API (OpenAPI/AsyncAPI), versões, compatibilidade (back/forward).
• Dependências de entrada/saída (upstream/downstream) com tipo (sync/async), criticidade, espera SLO.
• Orçamento de temporizadores/retrações, breakers, bolkhead-pula.
• Dados de cotas e limites de integração externa.

• `service: payments-api`
• Upstream: `user-profile` (sync), `risk-score` (async).
• Downstream: `PSP-X` (sync, квота 2k RPS), `ledger` (async).
• SLO: p99 ≤ 300 ms, 99. 9% uptime.
• Temporizadores: 200 ms para 'PSP-X', 150 ms para 'user-profile'.
• Retrai: 2 com atraso exponencial, jitter.
• Breaker: aberto em 30 s a 5% de erros/10 s.

4) SLO-exposição e «orçamento de latidão»

Na cadeia de chamadas sincronizadas, o SLO final é formado a partir da soma de atrasos e probabilidades de falhas.

• O orçamento da consulta é dividido de cima para baixo: SLO 500 ms de frente Edge 50 ms API 150 ms serviços de domínio 200 ms de provedor de 100 ms.
• O tempo para fora é mais curto do que para dentro: o chamador tem menos tempo interno total, para que os recursos sejam atualizados, em vez de escavar chamadas zombies.
• Retrai apenas para códigos seguros/exclusões e com jitter; sem retrações para os temporizadores de estreitos (senão «tempestade»).

5) Contratos e compatibilidade

Versionização da API: SemVer para contratos; backward-compatível alterações através dos campos «optional», extensões de esquema; a remoção é apenas através do «período de deprekate».
Consumer-driven contracts (CDC): testes de consumo (Pact-similares) são lançados contra o provedor em CI; O lançamento é bloqueado quando incompatível.
Diagramas (Async): versão de topics/eventos, evolução dos circuitos (Avro/JSON-Schema), política de «can-read-old/can-write-new».

6) Máquinas de engenharia de sustentabilidade

Timeouts: Separando o negócio SLA das expectativas técnicas; Cada ligação que sai é um tempo claro.
Retries + backoff + jitter: no máximo 2-3 tentativas, dada a idempotação.
Circuito Breaker: «queda rápida» na degradação do downstream; half-open amostras.
Bolkhead (isolamento de pool): para diferentes downstream - pool de fluxo/pol/conexões individuais.
Rate-limit/Leaky-bucket: para não matar downstream em picos.
Idempotency & dedução: chave de idempotação no nível de consulta/mensagem; avô leitor e fila de retais.
Cachês e folbeques: cachês locais/distribuídos, estatais «stale-while-revalidate», degradação de conteúdo.

outbound:
psp-x:
timeout_ms: 200 retries: 2 retry_on: [5xx, connect_error]
backoff: exponential jitter: true circuit_breaker:
error_rate_threshold: 0. 05 window_s: 10 open_s: 30 pool: dedicated-psp (max_conns: 200)

7) Observabilidade das dependências

Traçados distribuídos (TraceID, Baggage): veja o caminho da consulta por elos; dormindo para chamadas de saída com marcas 'peer. service`, `retry`, `timeout`.
Метрики per-dependency: `outbound_latency_p99`, `outbound_error_rate`, `open_circuit`, `retry_count`, `queue_lag`.

• Mapa de serviços com o indicador de cores SLO e costelas erradas.
• «Top N Dependências Problemáticas» na última semana.
• «Blast radius» é uma lista de serviços que serão afetados pela queda do X.
• Logi de correlação: incluir 'trace _ id '/' span _ id' nos registros.

8) Gerenciamento de lançamentos com dependências

Dependency-aware pipline: O lançamento do provedor é bloqueado se os testes CDC do consumidor são vermelhos.
Inclusão gradual (ficheflags): novos campos/endointos → para 1% dos consumidores → 10% → 100%.
Lançamentos canários: Verificamos as dependências essenciais e o «orçamento da latência» na parte do tráfego.
Compatibilidade de esquema: o produtor escreve «vNew» e os consórcios leem «vOld/vNew»; após a transição, «coleta de lixo» dos campos antigos.

9) Incidentes e escalações por conde

Identificamos um «verdadeiro responsável»: a correlação alert - se «PSP-X» se degradou, não o pagim de todo o «arbusto de pagamento», mas o dono da integração.
Ajuste automático: fichiflag «modo mínimo» (endpoints menos pesados, bandos cortados, fiapos não críticos).
Gardas de cascata: Limitando o paralelismo, desligando os retais em um ramo quente, abrindo o breaker com antecedência (pré-open).

• Diagnóstico: Quais dashboards/métricas, como verificar quotas/limites.
• Ações: reduzir RPS, mudar para o provedor de reserva, ativar temporariamente as respostas em dinheiro.
• Reverter e validar: recuperar parâmetros, certificar-se de p95/p99 e error-rate.

10) Matriz de criticidade de dependências

• Para os críticos, provedores duplos, breakers, balas individuais, testes de caos.
• Para os altos, pelo menos a degradação e o botão verde para desligar os fichas.
• Para os «médios/baixos», os limites para os retais e o orçamento das filas.

11) Processo: do inventário à operação

1. Mapear gráfico: recolher chamadas reais (traçados) + dependências declaratórias do catálogo.
2. Designar proprietários para cada serviço e integração externa - responsável on-call.
3. Definir SLO e orçamentos: latência/erro, timeouts/retraí/pula.
4. Formalizar contratos: OpenAPI/AsyncAPI, esquema e CDC.
5. Incluir pattern de estabilidade timeouts/retries/circuito/bulkhead.
6. Ajustar dashboards e alertas per-dependency.
7. Coloque o lançamento-gate, bloco de CDC/compatibilidade/canário.
8. Jogos-days regulares: experiências de caos para queda de costelas-chave.
9. O que aumentou a cascata, como reduzir o raio.

12) Alertas de dependência (ideias de regras)

• `outbound_error_rate{to="X"} > 3% FOR 10m` → warning; `>5% FOR 5m` → critical.
• `outbound_p99_latency{to="X"} > SLO1. 3 FOR 10m` → warning.

• ' circuito _ open

• ' retry _ rate baseline2 FOR 5m' + 'outbound _ rps> 0' → o risco de tempestade.

• `consumer_lag{topic="Y"} growth > threshold FOR 10m` + `hpa at max` → крит.

• ' usage _ queta\provider =» PSP-X «a.> 90% window '→ o aviso, a conversão automática das rotas.

13) Anti-pattern

«Um pool de fluxo total para todos os downstream». Total: head-of-line blocking. Divida as balas.
Sem temporizações/com retais sem fim. É assim que a tempestade nasce.
Retraias cegas de cirurgias não-ideais. Duply cancelamentos/apostas.
«BD» oculto como ponto de conectividade. Competição forte e bloqueios.
A API é alterada sem CDC ou plano de deprekate. Apanhem as baixas em massa.
Observabilidade por serviços, não por ligações. Não se vê onde a corrente está.

14) Dashboards: conjunto mínimo

Serviço Map: mapa interativo de serviços com métricas de costelas (latency/erro/volume).
Upstream/Downstream Overview: Para o proprietário do serviço, as dependências entrantes (quem liga) que saem (a quem chamamos) são «os melhores problemas».
Dependency Drilldown: cartão de ligação específica: p50/p95/p99, erros de classe, porcentagem de breaker aberto, retraí, pool de conexões, quotas/coast.
Release Context: anotações de lançamentos/fichiflags em gráficos de dependências.

15) Folha de cheque de implementação

• Catálogo de serviços com proprietários e contratos (OpenAPI/AsyncAPI).
• Gráfico completo de dependências a partir de traçados (atualizar diariamente).
• SLO de serviço e «orçamento de latência» para baixo na cadeia.
• Timeouts explícitos, retraí com jitter, breakers, bulkhead-isolamento.
• Testes CDC em CI como um gate de lançamento.
• Dashboard per-dependency e cartão de serviço.
• Alertas nas costelas + supressão por causa primária.
• Game-days: queda do provedor/cluster/topic e verificação de degradações.
• Plano de degradação: que fitas desativamos, que cachês ativamos.
• Postmortem regularmente com ações de redução de conectividade.

16) KPI qualidade de gerenciamento de dependências

Dependency MTTR: Mediana de recuperação da costela.
Blast Radius Index: média de serviços afetados quando um cai.
Coupling Score: proporção de dependências sync entre todos; Tendência de baixa.
CDC Pass Rate:% de lançamentos sem violação de contrato.
Retry Storms/mês: destino → 0.

Custo das chamadas externas em 1k RPS (ver o efeito de cachê/folbacks)

17) Início rápido (default)

Temporizações: 70% a 80% do orçamento do elo; o tempo superior da consulta <soma do valor interno.
Retrai: max 2, apenas para Idempotent 5xx/rede, com backoff + jitter.
Breaker: limite de 5% de erros em 10 s, open = 30 s, half-open provas.
Bolkhead: pool/limite de conexões selecionados para cada downstream.
CDC: Obrigatório para todas as APIs públicas e topics.
Preferência Async: onde você pode ir para eventos/filas (saída de hora).

18) FAQ

O que é mais importante, retraí ou breaker?
A: Ambos. Retraias salvam contra falhas de curto prazo, o breaker protege contra a degradação permanente e tempestades.

Como compreender que a ligação é «demasiado frágil»?
A: Alta correlação de erros, baixa reserva de timeouts, frequentes retraias, falta de folbex/dinheiro, longas cadeias sincronizadas.

Porquê o CDC se tivermos testes de integração?
A: O CDC capta as expectativas do consumidor e quebra o lançamento do provedor em caso de incompatibilidade - antes que o código chegue à proda.