Atualizações do ecossistema sem downthame

(Secção: Ecossistema e Rede)

1) Propósito e princípios zero-downtime

• Compatibilidade para frente/para trás (backward/forward) nos limites dos contratos.
• Gradual (progressivo delivery) em vez de «grande mudança».
• Observabilidade e reversibilidade: métricas, traçados, reversão rápida.
• Idempotidade e retais seguros para fluxos de rede e pagamentos.
• Isolamento de falhas: arquitetura cell, circuito-breakers, limites de fã-out.

2) Estratégias de lançamento sem downthame

Blue-Green - duas pilhas idênticas (Blue = prod, Green = new). O tráfego alterna atômico ao nível do balanceador com a possibilidade de reversão instantânea.
Canary é uma proporção gradual de tráfego (1%→5%→20%→50%→100%) com gates SLO.
Rolling - Atualização de pool de pool com teste de preparação e drenagem de conexões.
Shadow/Traffic Mirroring - Espelhar as solicitações de uma nova versão sem afetar as respostas.
A função Flags é uma mudança de negócio sobre a API inalterada (gradual rollout).
Dark Launch - a inclusão de grupos ocultos de lógica para telemetria e perfis.

Recomendação: para serviços críticos - combinação canary + rolling + função flags; para passeios e API - blue-green com mudança curta.

3) Compatibilidade contratual (API/eventos/protocolo)

API: versionização por URI/cabeçalho; adicionar campos - é válido, remover/mudar de nome - somente através da «janela de deprekeit».
Eventos: «apenas adição» de campos; as chaves são imutáveis; novos tipos - como novos temas/versões.
Esquemas (Avro/JSON-Schema/Protobuf): registro de esquema, compatibilidade 'BACKWARD' FULL '.
Protocolo de rede/R2R: versão handshake e capability negotion (nódulos anunciam versões suportadas/fici).
Gateways: adaptadores entre vN e vN+1 (transcoding/field maping) para o período de migração.

Política de despreceituário (exemplo): anúncio → ≥90 dias de aviso → caixa de seleção «deprecated» → remoção de campo/endpoint.

4) Migração de dados sem interrupção (Expand → Migrate → Contract)

1. Expand - Adicionar novas estruturas/índices/colunas (nullable/c default), duplo (dual-write) ao formato antigo e novo.
2. Migrate - migrações de fundo, backfill, validadores de consistência; leitura através de um adaptador que suporta ambos os esquemas.
3. Contract - Desativar a leitura/gravação no esquema antigo, remover a dívida técnica após a conclusão da «janela de deprekate».

sql
-- Expand
ALTER TABLE payouts ADD COLUMN payout_ref TEXT NULL;
CREATE INDEX CONCURRENTLY ix_payouts_ref ON payouts(payout_ref);

-- Migrate (batch + idempotent)
UPDATE payouts SET payout_ref = concat('ref_', id) WHERE payout_ref IS NULL;

-- Contract (after compatibility window)
ALTER TABLE payouts ALTER COLUMN payout_ref SET NOT NULL;

Transacionalidade de eventos: use o Outbox (transação com gravação de evento) + CDC para garantir a entrega.

5) Compostos de longa vida e drenagem

Graceful shutdown: SIGTERM → parar de receber novas solicitações → expor 'readiness = fail' → esperar a drenagem WebSocket/HTTP2/QUIC Striptease → fechar.
Connect draining no balanceador: 'deregister _ delay' 30-120 s, sticky-sessões através de tokens em vez de IP.
Back-pressure: limitar novos upstream ao crescimento p99 _ latency.

6) Versionização SDK e clientes

SemVer para SDK; Um ramo LTS com janela de suporte avançada (por exemplo, 12 meses).
Policy: «pelo menos duas versões menores ativas»; telemetria para os clientes em versões; avisos automáticos de necessidade de upgrade.
Alterações críticas (security): sinalização forçada de desativação de versões antigas através do gateway após a deadline.

7) Atualizações de protocolos e nós da rede

Soft-fork: ampliação de regras sem violação de nós antigos (capabilities).
Hard-fork: janela pré-anunciada, dupla validação, «validadores canários», proteção contra conflitos «reorg/rollback», time-lock para ativação.
Updates de cadeia cruzada: pontes governance transmitem sinais de ativação; em caso de desabastecimento - circuito local-breaker.

8) Configurações e segredos como dados

Config-service centralizado com versioning, assinaturas digitais e retrocesso.
Segredos rotation sem downthame: chaves duplas (old/new), inclusão alternada; interrupções zero para KMS/PKI.
Função-flags em estoque separado, auditoria de ativações/desligamentos.

9) Lançamento Pipeline e «gates» automáticos

Стадии: build → unit → security scan → e2e/stage → shadow → canary → 100%.

• Error-budget burn-rate, p95/p99 latency, erro-rate, redução de sucess-rate eventos/pagamentos, crescimento das filas dead-better.
• Reversão automática para violação do SLO em qualquer uma das etapas.

yaml release:
strategy: canary steps:
- name: shadow traffic_mirror: 5%
gates: [no_data_loss, no_pii_leak]
- name: canary_1 traffic: 1%
gates: [error_rate<0. 2%, p99<400ms]
- name: canary_2 traffic: 10%
gates: [slo_ok_1h, zero_deadletters]
- name: rollout traffic: 100%
gates: [stability_6h]
- name: bake duration: 24h action: finalize_or_rollback

10) Observabilidade e SLO para lançamentos

• p95/p99 latency por endpoentes; error-rate (5xx + fatais 4xx); sucess-rate eventos; porção de retrações; Fila de fila; «relay» em P2P; Proporção de clientes em versões.

• p99 API ≤ 400 ms; error-rate ≤ 0. 2%; sucess-rate eventos ≥ 99. 5%; fila de fila ≤ 2 c; MTTR reversão ≤ 15 min
• Dashboards de lançamento: comparação «antes/depois», canários, mapa de dependências (service map), alertas burn-rate 1h/6h.

11) Reversões e «kill-switch»

Auto-recall: guarde os últimos artefatos e configs «bons»; «1 botão» rollback no balanceador (Blue←Green).
Partial rollback: O fichiflag desliga a nova lógica enquanto mantém o binário.
Data rollback: somente para «read-paths»; para «write-paths» - Migrações seguras (nunca remova colunas antigas até a janela terminar).
Kill-switch: uma bandeira centralizada para desativar um subsistema instável.

12) Testes sem interrupção

Testes contratuais de proda contra clientes stab (consumer-driven).
Testes de sintonia de compatibilidade (schema-compat).
Chaos testes de stejing: desligamento de% dos nós/regiões, degradação de DHT/TURN/KMS/DNS, «tempestade de retrações».
Testes de carga/remarcação: regiões canárias e rotas quentes.

13) Regulamentos de comunicação e complacência

Notas de lançamento: O que muda, o impacto, as janelas/deadline do deprecate, as ações para os parceiros.
SLA respostas a incidentes: MTTA ≤ 5 min, primeiro update status ≤ 15 min, pós-mortem ≤ 72 h.
Auditoria de vestígios, vinculação de todas as alterações de config e lançamentos a candidaturas/propousados, assinaturas de artefactos.

14) Casos especiais

Fluxos de pagamento/financiamento: Idempotidade rigorosa, dedução de idempotency-key, outbox + CDC, migração «não destrutiva» apenas.
WebSocket/striam: versão do protocolo em handshake, um recôncavo resumido (resume tokens).
Cash/edge: 'stale-while-revalidate', versão dupla do cachê, higiene TTL durante o período de lançamento.
Clientes móveis: rolout gradual em estoques, update forçado em edições de segurança.

15) Folha de cheque zero-downtime

1. Compatibilidade contratual e esquema de registro configurado.
2. descrito e automatizado.
3. O Balanço/Ingress suporta conexões blue-green e drenagem.
4. Canary-pipeline com gates SLO e auto-revezamento.
5. As feições-flags e kill-switch estão disponíveis em 24/7.
6. Outbox + CDC e idempotação estão incluídos para todos os caminhos write.
7. As dashboards de lançamento e alertas burn-rate estão ativas.
8. Comunicações e políticas de deprekate são anunciadas aos parceiros com antecedência.
9. Ensaio semanal de reversão; chaos-day trimestral.

16) Glossário

Progressive delivery é uma emissão gradual com controle de risco.
Schema registry - armazenamento de versões de esquemas com políticas de compatibilidade.
Outbox/CDC - modelo de publicação garantida de eventos de transações.
Blue-Green - pilhas paralelas com mudança de tráfego atômico.
Canary - aumentar gradualmente a proporção de tráfego na nova versão.
Graceful shutdown/draining - conclusão correta de conexões ativas.

Resultado: o downthame zero não é um truque, mas um sistema: contratações, compatibilidade, estratégias de lançamento graduais, observabilidade, migrações seguras e retrocesso garantido. Seguindo este quadro, o ecossistema é atualizado de forma rápida, previsível e sem dor para os usuários e parceiros.