Flujos de datos entre nodos

(Sección: Ecosistema y Red)

1) Esencia y objetivos

• Previsibilidad: SLO estables por retraso/éxito/frescura.
• Fiabilidad: resistencia a pérdidas, duplicados, reorgas.
• Seguridad y cumplimiento: cifrado, firmas, residencia.
• Escalabilidad: geo-distribución, partición, QoS.

2) Taxonomía de flujos

1. Control Plane: configuraciones, fichflags, políticas de enrutamiento/límites.
2. Data Plane es un evento: eventos de dominio ('depósito.', 'payout.', 'puente.').
3. Data Plane - stream: flujos de larga vida (gRPC/WebSocket) para señales y métricas en vivo.
4. Batch/Backfill: descargas de cortes históricos, réplicas, snapshots.
5. Replicación/anti-entropía: state sync, merclización, flujos CRDT.
6. Teleemetría/observabilidad: registros/métricas/tracks side-band, no interfieren con el UX principal.

Cada tipo corresponde a las clases de QoS y a sus propias reglas de retroceso/orden.

3) Topologías y enrutamiento

Hub-and-Spoke: hubs regionales como neumáticos; spooks - nudos de roles.
Mesh/P2P: célula parcial para replicación/gossip.
Edge-Tiered: slim edge gateways (rate-limit/caché) → clústeres regionales gruesos.
Geo-Routing: Anycast/Latency-Aware LB + reglas de residencia.

Clave - partición: 'partition _ key = chainId' tenant 'topic' entityId 'proporciona un orden y una escala predecibles.

4) Transporte y formatos

HTTP/2/3, gRPC/QUIC - baja latencia, multiplexación, keepalive.
Kafka/Pulsar/NATS: colas con grupos de persistencia/lotes/consumidores.
WebSocket - Eventos de inserción y canales en vivo.
Formatos: Protobuf/Avro (circuitos con evolución), JSON para APIs externas.
Direccionamiento hash y recibos Merkle para verificar la integridad.

5) Orden, entrega y finalización

• At-least-once (predeterminado; se requiere idempotencia/dedoup).
• Exactly-once-efecto a través de Outbox/Inbox + consumer idempotente.
• Orden: garantizado dentro del partido; el orden interparto no está garantizado.
• Finalización: estados 'observed → confirmed (K) → finalized → invalidated (reorg)'; para optimistic - ventana de disputa.

6) Idempotencia y dedoup

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

• Upsert por llave, TTL de la ventana del dedoop ≥ 72 h.
• En el conflicto, payload es la política «fuente de la verdad» (prioridad, versión, firma).
• Para consultas HTTP, el encabezado 'Idempotency-Key' + registro de respuestas.

7) Colas, backpressure y cuotas

Colas: lotes por clave; DLQ para mensajes «venenosos».
Backpressure: créditos/tokens, restricción max-inflight, circuit-breaker.
Cuotas/QoS: P0 (crítico), P1 (producto), P2 (bulk). Grupos/límites de RPS/bytes/s/suscripciones separados.
Control de Admision: falla temprana de solicitudes «caras», guardia por rangos/tamaños.

8) Coherencia y modelos de datos

Read-you-write dentro del lote/nodo.
Consistencia eventual entre regiones/partidos.
CRDT para la replicación libre de conflictos de algunos conjuntos (contadores, conjuntos).
Snapshots + registros para bootstrap rápido y replay determinista.

9) Seguridad y confianza

mTLS entre nodos, pinning de claves, rotación.
Firmas de mensajes/webhooks, marca de tiempo y ventana anti-replay.
Cifrado en tránsito/en reposo; segregación de claves regionales.
PII-minimización: tokenización, prohibición de datos personales en etiquetas/métricas.

10) Eficiencia: por lotes, compresión, caché

Batching: agrupar mensajes pequeños para reducir la sobrecarga.
Compression: zstd/gzip con diccionarios seguros.
Caché: respuestas negativas y referencias «calientes»; TTL y discapacidad por evento.

11) Esquemas de datos (referencias)

Registro de flujos/lotes

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 idempotente)

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/cuarentena

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 y límites

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

Finalización y ventanas

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

Routing/Residence

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

13) Observabilidad: SLI/SLO

• Latency p95/p99 (ingress→egress, per-stream/QoS).
• Success Rate / Drop Rate.
• Queue Lag p95 y consumer lag por lotes.
• Freshness p95 (ingest→consume).
• Reorg/Invalidated Rate (si onchain).
• Dedup Efficiency (% de las tomas absorbidas de forma idempotente).
• Geo-Hit Ratio (servido localmente).

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

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

14) Patrones de consumo

Outbox/Inbox: publicación atómica y aplicación idempotente.
Exactly-once-efecto: almacenar la última clave y versión aplicada.
Watermarks: procesamiento de eventos atrasados (data late).
Idempotent Side-Effects: consultas externas con sólo una clave y un registro de respuestas.

15) Regímenes de degradación

Modo único finalizado: sólo emitimos eventos finalizados.
Cache-only para guías, congelación de métodos pesados.
Throttle P2 y «régimen de dieta» para streams (frecuencia de actualización reducida).
Sólo lectura para API menores.

16) Lanzamientos y migraciones sin downtime

Blue-Green/Canary a través de los flujos y los consumidores.
Schema-first: sólo agregar campos; MAJOR son versiones paralelas de los topics.
Migraciones offset's: shadow-consumers, comparación de lag/éxito, conmutación.

17) Normas de funcionamiento

Diariamente: informe SLO (latency/success/lag/freshness), auditoría de firmas, verificación DLQ.
Semanalmente: revisión de lotes/cuotas, prueba de DR (bootstrap desde snapshot), análisis de Dedup Efficiency.
Mensualmente: pruebas de chaos (loss/jitter, fallo del bróker, reorg-bourst), revisión de las ventanas de finalidad.
Antes del lanzamiento: canario ≥120 min, SLO-gates, plan de retroceso.

18) Incidentes de Playbook

A. Explosión de Queue-Lag/Consumer-Lag

1. Aumentar consumers/KEDA; 2) redistribuir los lotes; 3) congelar el P2 y el bulk-jobe; 4) análisis de claves «calientes».

B. Crecimiento P95 Latency P0

1. P2-throttle, priorización de P0; 2) escalar puertas de enlace/corredores; 3) caché sólo para guías; 4) outlier-ejection.

C. Alto DLQ/doblaje

1. Comprobar la clave de idempotencia/TTL; 2) reforzar el dedoup; 3) limitar al productor ruidoso; 4) réplica después de la fix.

D. Drift esquemas/contratos

1. Habilitar el modo strict (cortar el modo invisible); 2) notificar al productor; 3) liberar el adaptador; 4) actualizar los linters.

E. Incumplimiento de residencia/firma

1. Unidad de exportación/canal; 2) rotación de llaves/sert; 3) auditoría y post mortem; 4) actualización de políticas.

19) Lista de verificación de implementación

1. Defina los tipos de subprocesos y la clave de partición.
2. Incluya la idempotencia/dedoup y la finalización con ventanas K/espora.
3. Configure colas, QoS, cuotas y backpressure.
4. Ejecute mTLS/firmas y la política de residencia.
5. Introduzca esquemas/registros (streams, offsets, dlq) y telemetría SLI/SLO.
6. Organice canary/blue-green y migre circuitos sin downtime.
7. Trabaje con los modos de degradación y los playbooks de incidentes.

20) Glosario

Backpressure - Control de la carga de entrada (créditos/tokens/límites).
DLQ es una «cola muerta» para mensajes problemáticos.
CRDT - Estructuras de datos con resolución de conflictos sin coordinación.
Finalidad - irreversibilidad del evento/estado.
Exactly-once-efecto - repetición-resultado seguro encima de la entrega en-least-once.
Watermark: marca de progreso de procesamiento para eventos posteriores.
Outlier-ejection: elimina las instancias degradadas de la agrupación.

En resumen: los flujos de datos entre nodos no son simplemente «cola y oyente», sino una disciplina sistémica de orden, finalización, idempotencia, seguridad y observabilidad. Las claves de partición estándar, QoS/cuotas, esquemas estrictos y SLO, junto con los modos de degradación y los playbooks, dan al ecosistema canales de datos sostenibles a escala y bajo auditoría.