Fluxo de dados entre nós

(Secção: Ecossistema e Rede)

1) Essência e objetivos

• Previsibilidade: SLO estável em atraso/sucesso/frescura.
• Confiabilidade: resistência a perdas, duplicados, reorgias.
• Segurança e complicação, criptografia, assinaturas, residência.
• Escalabilidade: distribuição geo, particionamento, QoS.

2) Taxonomia de fluxo

1. Controle Plane: configs, fichiflags, políticas de rotação/limites.
2. Data Plane - Eventos de domínio ('deposit', 'payout', 'bridge').
3. Data Plane - Fluxo de longa duração (gRPC/WebSocket) para sinais e métricas ao vivo.
4. Batch/Backfill: carregamentos de cortes históricos, réplicas, solavancos.
5. Replicação/anti-entropia: state sync, merceação, fluxos CRDT.
6. Telemetria/observabilidade: logs/métricas/trailers side-band, não atrapalham o UX básico.

Cada tipo corresponde às classes e às suas próprias regras de retais/ordem.

3) Topologias e rotação

Hub-and-Spoke: Hub regional como pneus; spooks são nós de papéis.
Mesh/P2P: capacidade parcial para replicação/governo.
Edge-Tiered: passarelas finas (rate-limit/dinheiro) → clusters regionais gordos.
Geo-Roting: Anycast/Latency-Aware LB + regras de residência.

A chave é particionar: 'partition _ key = chainId'tenant'topic'entityId' dá ordem e escala previsíveis.

4) Transporte e formatos

HTTP/2/3, gRPC/QUIC - baixa latência, multiplexação, keepalive.
Kafka/Pulsar/NATS - filas com personalidade/partições/grupos de consoante.
WebSocket - eventos push e canais ao vivo.
Formatos: Protobuf/Avro (esquemas evolutivos), JSON para API externa.
Endereço hesh e recibos Merkle para verificação de integridade.

5) Ordem, entrega e finalização

• At-least-once (padrão; é preciso idimpotência/dedup).
• Efeito exactly-once através do Outbox/Inbox + Consumer Idumpotente.
• Ordem: garantida dentro da partição; a ordem interpartidária não é garantida.
• Finalização: estatais 'observed → confermed (K) → finalizações → invalidated (reorg)'; para optimistic - janela de disputa.

6) Idempotidade e dedução

• `idempotency_key = ${chainId}|${block}|${tx}|${logIndex}|${type}`

• Upsert à chave, TTL janelas de dedução ≥ 72 h.
• Para o conflito payload - política «origem da verdade» (prioridade, versão, assinatura).
• Para consultas HTTP, o título é 'Idempotency-Key' + registro de respostas.

7) Filas, backpressure e quotas

Filas: partituras por chave; DLQ para mensagens «venenosas».
Backpressure: créditos/tokens, limite max-infight, circuito-breaker.
Quotas/QoS: P0 (crítico), P1 (produto), P2 (bulk). Balas/limites RPS/bytes/s/assinaturas separadas.
Adesion control: Falhas iniciais de solicitações «caras», guard por intervalo/tamanho.

8) Coerência e modelos de dados

Read-you-write dentro da partitura/nó.
Eventual Consistency entre regiões/partituras.
CRDT para a replicação conflito-frei de alguns conjuntos (contadores, múltiplos).
Snapshots + revistas para bootstrap rápido e determinada replay.

9) Segurança e confiança

Entre nós, pinning de chaves, rotação.
Assinaturas de mensagens/webhooks, marca de hora e janela anti-replay.
Encriptação no caminho/em paz; segregação de chaves regionais.
PII-Minimização: Tocenização, proibição de dados pessoais em editoras/métricas.

10) Eficiência: paquera, compressão, dinheiro

Batching: agrupamento de mensagens menores para redução de overhead.
Composto: zstd/gzip com dicionários seguros.
Em dinheiro: respostas negativas e guias quentes; TTL e deficiência por evento.

11) Circuitos de dados (arbitragens)

Registro de fluxo/partituras

sql
CREATE TABLE streams (
name TEXT PRIMARY KEY,
partitions INT,
qos TEXT,        -- P0    P1    P2 retention_days INT,
schema_version TEXT
);

CREATE TABLE offsets (
stream TEXT, partition INT, consumer_group TEXT,
offset BIGINT, updated_at TIMESTAMPTZ,
PRIMARY KEY (stream, partition, consumer_group)
);

Registro de eventos (upsert idempotental)

sql
CREATE TABLE events_core (
id UUID PRIMARY KEY,
idempotency_key TEXT UNIQUE,
ts TIMESTAMPTZ,
partition_key TEXT,
type TEXT,
payload JSONB,
status TEXT,      -- observed    confirmed    finalized    invalidated signature TEXT
);

DLQ/quarentena

sql
CREATE TABLE dlq (
id UUID PRIMARY KEY,
stream TEXT, partition INT, offset BIGINT,
reason TEXT, payload JSONB, ts TIMESTAMPTZ
);

12) Políticas (YAML)

QoS e limites

yaml qos:
P0: { ack_timeout_ms: 2000, retries: 3, backoff_ms: [100,400,800], rps_per_org: 1500 }
P1: { ack_timeout_ms: 5000, retries: 2, rps_per_org: 800 }
P2: { best_effort: true, rps_per_org: 200 }
limits:
max_message_bytes: 1048576 max_stream_subscriptions_per_client: 20

Finalização e janelas

yaml finality:
eth-mainnet: { k: 12 }
polygon:   { k: 256 }
optimistic: { k: 0, challenge_minutes: 20 }

Roteamento/Residência

yaml routing:
prefer_local_region: true fallback: [nearest_healthy, master_hub]
residency:
eu: ["eu"]
uk: ["uk"]

13) Observabilidade: SLI/SLO

• Latency p95/p99 (ingress→egress, per-stream/QoS).
• Success Rate / Drop Rate.
• Queue Lag p95 e consumer lag por partições.
• Freshness p95 (ingest→consume).
• Reorg/Invalidated Rating (se onchain).
• Dedup Efficiency (% das duplicações absorvidas idempotadamente).
• Geo-Hit Ratio (atendido localmente).

• P0 latency p95 ≤ 400 ms; Success ≥ 99. 95%; Queue-lag p95 ≤ 2 с; Freshness p95 ≤ 60 с.
• Dedup efficiency ≥ 99%; DLQ ≤ 0. 1% do tráfego.

Dashboards: Streams Core/Lag & Freshness/ QoS & Errors/Geo/Security (mTLS/assinaturas).

14) Pattern de consumidores

Outbox/Inbox: publicação atômica e aplicação idumpotente.
Efeito exactly-once: armazene a última chave e versão aplicadas.
Watermarks: processamento de eventos atrasados (late data).
Idempotent Side-Effects: solicitações externas apenas com a chave e o registro de respostas.

15) Regimes de degradação

Modo Finalized-only: Apresentamos apenas eventos finalizados.
Cachê-only para guias, congelamento de métodos pesados.
Throttle P2 e «modo de dieta» para striptease (menor taxa de atualização).
Read-only para API secundário.

16) Lançamentos e migrações sem downthame

Blue-Green/Canary para fluxos e consoadores.
Schema-first: apenas adição de campos; MAJOR - versões paralelas de topics.
Migrações offset 'ov: shadow-consoadores, comparação de lag/sucesso, mudança.

17) Regulamentos operacionais

Diariamente: relatório SLO (latency/sucess/lag/freshness), auditoria de assinaturas, verificação de DLQ.
Semanalmente: revisão de partituras/quotas, teste de DR. (bootstrap de snapshot), análise de Dedup Efficiency.
Mensalmente: chaos-testes (loss/jitter, corretor falhado, reorg-burst), revisão de janelas de finality.
Antes do lançamento, canário, minas, gates SLO, plano de reversão.

18) Playbook incidentes

A. Explosão Queue-Lag/Consumer-Lag

1. Aumentar consoadores/KEDA; 2) redistribuir as partições; 3) congelar P2 e bulk-jobs; 4) Análise de chaves quentes.

B. Crescimento p95 Latency P0

1. P2-throttle, priorização P0; 2) Dimensionar gateways/corretores; 3) dinheiro-apenas para guias; 4) outlier-ejection.

C. Alta DLQ/duplicação

1. Verificar a chave de idempotação/TTL; 2) Reforçar o deduto; 3) limitar o produtor barulhento; 4) réplicas depois do fix.

D. Drivt diagramas/contratos

1. Activar o modo strict (corte de não-alídeos); 2) notificar o produtor; 3) soltar o adaptador; 4) Atualizar as lentes.

E. Violação de residência/assinaturas

1. Unidade de exportação/canal; 2) rotação de chaves/sertos; 3) auditoria e pós-mortem; 4) Atualização de políticas.

19) Folha de cheque de implementação

1. Defina os tipos de fluxo e a chave de partilha.
2. Inclua idempotidade/dedupo e finalização com janelas K/disputa.
3. Configure filas, QoS, quotas e backpressure.
4. Execute mTLS/assinaturas e política de residência.
5. Digite os circuitos/registros (streams, offsets, dlq) e telemetria SLI/SLO.
6. Organize canary/blue-green e migre circuitos sem downthame.
7. Mantenha os regimes de degradação e playbooks de incidentes.

20) Glossário

Backpressure - controle de carga de entrada (créditos/tokens/limites).
DLQ - «fila morta» para mensagens problemáticas.
CRDT - estruturas de dados com resolução de conflitos sem coordenação.
Finality - irreversibilidade de evento/estado.
O efeito exactly-once é uma repetição-segura em cima da entrega at-least-once.
Watermark é uma marca de progresso de processamento para eventos recentes.
Outler-ejation é a exclusão de instâncias degradadas do pool.

Resultado: os fluxos de dados entre nós não são apenas «fila e ouvinte», mas uma disciplina de sistema de ordem, finalização, idempotidade, segurança e observabilidade. As chaves de partilha padrão, QoS/quotas, circuitos rigorosos e SLO, juntamente com regimes de degradação e playbooks, fornecem ao ecossistema canais de dados sustentáveis em escala e sob auditoria.