Flux de données entre les nœuds

(Section : Écosystème et réseau)

1) Essence et objectifs

• Prévisibilité : SLO stable en termes de retard/succès/fraîcheur.
• Fiabilité : résistance aux pertes, aux doublons, aux réorgues.
• Sécurité et conformité : cryptage, signatures, résidence.
• Évolutivité : géo-distribution, partitionnement, QoS.

2) Taxonomie des flux

1. Control Plane : fligs, ficheflags, politiques de routage/limites.
2. Data Plane est un événement : événements de domaine ('deposit.', 'payout.', 'bridge.').
3. Data Plane - stream : flux à longue durée de vie (gRPC/WebSocket) pour les signaux et les métriques en direct.
4. Batch/Backfill : téléchargements de tranches historiques, reliques, snapshots.
5. Réplication/anti-entropie : sync d'état, merclisation, flux CRDT.
6. Téléémétrie/observabilité : les logs/métriques/trajets side-band, n'interfèrent pas avec l'UX principal.

Chaque type correspond à des classes QoS et à ses propres règles de rétroaction/ordre.

3) Topologies et routage

Hub-and-Spoke : maisons régionales comme pneus ; les spooks sont les nœuds des rôles.
Mesh/P2P : maillage partiel pour la réplication/gossip.
Edge-Tiered : passerelles edge minces (rate-limit/cache) → grappes régionales épaisses.
Geo-Routing : Anycast/Latency-Aware LB + règles de résidence.

La clé est le lot : 'partition _ key = chainId' tenant 'topic' entityId 'donne un ordre et une échelle prévisibles.

4) Transport et formats

HTTP/2/3, gRPC/QUIC - faible latence, multiplexage, keepalive.
Kafka/Pulsar/NATS sont des files d'attente avec des groupes/lots/consumer.
WebSocket - événements push et chaînes live.
Formats : Protobuf/Avro (schémas évolutifs), JSON pour les API externes.
Hachage et reçus Merkle pour la vérification de l'intégrité.

5) Ordre, livraison et finalisation

• At-least-once (par défaut ; idempotence/dedup).
• Effet exactly-once via Outbox/Inbox + consumer idempotent.
• Ordre : garanti dans le lot ; l'ordre interprofessionnel n'est pas garanti.
• Finalisation : statut « observé → confirmé (K) → finalisé → invalidé (reorg) » ; pour optimistic - fenêtre de controverse.

6) Idempotence et dedup

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

• Upsert par clé, TTL de la fenêtre de déduplication ≥ 72 h.
• Sur le conflit, payload est la politique « source de vérité » (priorité, version, signature).
• Pour les requêtes HTTP, l'en-tête 'Idempotency-Key' + journal des réponses.

7) Files d'attente, backpressure et quotas

Files d'attente : lots par clé ; DLQ pour les messages « toxiques ».
Backpressure : crédits/tokens, limitation max-inflight, circuit-breaker.
Quotas/QoS : P0 (critique), P1 (produit), P2 (bulk). Pools séparés/limites RPS/bytes/s/abonnements.
Contrôle d'admission : échec précoce des demandes « chères », garde par fourchettes/tailles.

8) Cohérence et modèles de données

Read-you-write dans le lot/nœud.
Consistency eventual entre les régions/partis.
CRDT pour la réplication conflit-frites de certains jeux (compteurs, multiples).
Snapshots + logs pour bootstrap rapide et replay déterministe.

9) Sécurité et confiance

mTLS entre les nœuds, pincement des clés, rotation.
Signatures de messages/webhooks, horodatage et fenêtre anti-replay.
Cryptage en transit/au repos ; ségrégation des clés régionales.
Minimisation des PII : Tokenization, interdiction des données personnelles dans les labels/métriques.

10) Efficacité : Empilement, compression, cache

Batching : regroupement de petits messages pour réduire l'overhead.
Compression : zstd/gzip avec des dictionnaires sécurisés.
Cache : réponses négatives et annuaires « chauds » ; TTL et handicap par événement.

11) Schémas de données (références)

Registre des flux/lots

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

Journal des événements (idempotent upsert)

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

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

12) Politiques (YAML)

QoS et 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

Finalisation et fenêtres

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

Itinérance/résidence

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

13) Observabilité : SLI/SLO

• Latency p95/p99 (ingress→egress, per-stream/QoS).
• Success Rate / Drop Rate.
• Queue Lag p95 et consumer lag par lot.
• Freshness p95 (ingest→consume).
• Reorg/Taux invalidé (si onchane).
• Efficacité de Dedup (% des prises absorbées idempotent).
• Geo-Hit Ratio (desservi localement).

• P0 latitude p95 ≤ 400 ms ; Success ≥ 99. 95%; Queue-lag p95 ≤ 2 с; Freshness p95 ≤ 60 с.
• Dedup efficiency ≥ 99%; DLQ ≤ 0. 1 % du trafic.

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

14) Modèles de consommateurs

Outbox/Inbox : publication atomique et application idempotente.
Effet exactly-once : Stockez la dernière clé appliquée et la version.
Watermarks : traitement des événements en retard (late data).
Idempotent Side-Effects : requêtes externes avec clé et journal de réponses uniquement.

15) Modes de dégradation

Mode finalisé : nous ne produisons que des événements finalisés.
Cache-only pour les manuels, gel des méthodes lourdes.
Throttle P2 et « régime alimentaire » pour les strimes (taux de renouvellement réduit).
Read-only pour les API secondaires.

16) Releases et migrations sans downtime

Blue-Green/Canary par flux et consumers.
Schema-first : uniquement l'ajout de champs ; MAJOR - versions parallèles des tops.
Migration offset's : shadow-consumers, comparaison lag/succès, commutation.

17) Règlements opérationnels

Quotidien : rapport SLO (latency/success/lag/freshness), vérification des signatures, vérification DLQ.
Hebdomadaire : révision des lots/quotas, test DR (bootstrap de snapshot), analyse Dedup Efficiency.
Mensuel : tests de chaos (loss/jitter, défaillance du courtier, reorg-burst), révision des fenêtres de finalité.
Avant la sortie : canari ≥120 min, SLO-gates, plan de retour.

18) Playbook des incidents

A. Explosion de Queue-Lag/Consumer-Lag

1. Augmenter les consumers/KEDA ; 2) redistribuer les lots ; 3) congeler les jobs P2 et bulk ; 4) analyse des clés « chaudes ».

B. Croissance p95 Latitude P0

1. P2-throttle, priorité P0 ; 2) mettre à l'échelle les passerelles/courtiers ; 3) cache uniquement pour les manuels ; 4) outlier-ejection.

C. DLQ élevé/doublage

1. Vérifier la clé d'idempotence/TTL ; 2) renforcer le dedup ; 3) limiter le producteur bruyant ; 4) braquage après la fixation.

D. Drift schémas/contrats

1. Activer le mode strict (couper les modes non valides) ; 2) aviser le producteur ; 3) libérer l'adaptateur ; 4) mettre à jour les linters.

E. Violation de résidence/signature

1. Unité d'exportation/canal ; 2) rotation des clés/serts ; 3) audit et post-mortem ; 4) mise à jour des politiques.

19) Chèque de mise en œuvre

1. Définissez les types de flux et la clé de lot.
2. Incluez l'idempotence/dedup et la finalisation avec les fenêtres K/spot.
3. Configurez les files d'attente, QoS, quotas et backpressure.
4. Exécutez mTLS/signature et politique de résidence.
5. Entrez les schémas/registres (streams, offsets, dlq) et la télémétrie SLI/SLO.
6. Organisez canary/blue-green et la migration des circuits sans downtime.
7. Utiliser les modes de dégradation et les pleybooks d'incident.

20) Glossaire

Backpressure - Contrôle de la charge d'entrée (crédits/tokens/limites).
DLQ est la « file d'attente morte » pour les messages problématiques.
CRDT - Structures de données avec résolution de conflits sans coordination.
Finality - irréversibilité de l'événement/état.
L'effet exactly-once est un résultat sécurisé sur la livraison at-least-once.
Watermark est une marque de progression du traitement pour les événements tardifs.
Outlier-ejection est l'exclusion des instances dégradées du pool.

Résultat : les flux de données entre les nœuds ne sont pas seulement une « file d'attente et un auditeur », mais une discipline systémique de l'ordre, de la finalisation, de l'idempotence, de la sécurité et de l'observabilité. Les clés de lot standard, QoS/quotas, schémas rigoureux et SLO, ainsi que les modes de dégradation et les playbacks, donnent à l'écosystème des canaux de données durables à l'échelle et sous audit.