Datenflüsse zwischen Knoten

(Abschnitt: Ökosystem und Netzwerk)

1) Wesen und Ziele

• Vorhersagbarkeit: Stabile SLOs durch Verzögerung/Erfolg/Frische.
• Zuverlässigkeit: Widerstand gegen Verluste, Duplikate, Wiederholungen.
• Sicherheit und Compliance: Verschlüsselung, Signaturen, Wohnsitz.
• Skalierbarkeit: Geo-Distribution, Partitionierung, QoS.

2) Taxonomie der Ströme

1. Steuerebene: Configs, Ficheflags, Routing-/Limitrichtlinien.
2. Data Plane - event: domain events ('deposit.', 'payout.', 'bridge.').
3. Data Plane - Stream: Langlebige Streams (gRPC/WebSocket) für Signale und Live-Metriken.
4. Batch/Backfill: Downloads von historischen Schnitten, Repliken, Schnappschüssen.
5. Replikation/Anti-Entropie: State-Sync, Merklisierung, CRDT-Streams.
6. Telemetrie/Beobachtbarkeit: Logs/Metriken/Seitenband-Traces, stören nicht die Haupt-UX.

Jeder Typ entspricht QoS-Klassen und eigenen Retray-/Ordnungsregeln.

3) Topologien und Routing

Hub-and-Spoke: regionale Hubs als Reifen; Spooks sind Rollenknoten.
Mesh/P2P: partielle Zellularität für Replikation/Gossip.
Edge-Tiered: Dünne Edge-Gateways (Rate-Limit/Cache) → dicke regionale Cluster.
Geo-Routing: Anycast/Latency-Aware LB + Aufenthaltsregeln.

Der Schlüssel ist die Partitionierung: 'partition _ key = chainId' tenant 'topic' entityId 'gibt eine vorhersagbare Ordnung und Skala.

4) Transport und Formate

HTTP/2/3, gRPC/QUIC - niedrige Latenz, Multiplexing, keepalive.
Kafka/Pulsar/NATS - Warteschlangen mit Persistenz/Parties/Consumer-Gruppen.
WebSocket - Push-Events und Live-Kanäle.
Formate: Protobuf/Avro (Schaltungen mit Evolution), JSON für externe APIs.
Hash-Adressierung und Merkle-Quittungen zur Integritätsprüfung.

5) Bestellung, Lieferung und Finalisierung

• At-least-once (Standard; Idempotenz/Dedup erforderlich).
• Exactly-once-Effekt durch Outbox/Inbox + idempotent consumer.
• Ordnung: innerhalb der Partei garantiert; Die parteiübergreifende Ordnung ist nicht gewährleistet.
• Finalisierung: Status „observed → confirmed (K) → finalized → invalidated (reorg)“; für optimistic das Streitfenster.

6) Idempotenz und Dedup

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

• Upsert durch Schlüssel, TTL des Deduplexfensters ≥ 72 Stunden.
• Auf dem Konflikt payload - die Politik „die Quelle der Wahrheit“ (die Priorität, die Version, die Unterschrift).
• Für HTTP-Anfragen - Header 'Idempotency-Key' + Antwortprotokoll.

7) Warteschlangen, Backpress und Quoten

Warteschlangen: Parteien nach Schlüssel; DLQ für „giftige“ Nachrichten.
Backpressure: Credits/Token, Max-Inflight-Limit, Circuit-Breaker.
Quoten/QoS: P0 (kritisch), P1 (Produkt), P2 (Masse). Getrennte Pools/RPS/Bytes/s/Abonnements.
Admission Control: frühzeitige Ablehnung von „teuren“ Anfragen, Schutz nach Bereichen/Größen.

8) Konsistenz und Datenmodelle

Read-you-write innerhalb einer Partei/eines Knotens.
Eventual Consistency zwischen Regionen/Parteien.
CRDT für die konfliktfreie Replikation einiger Sätze (Zähler, Mengen).
Snapshots + Logs für schnelles Bootstrap und deterministisches Replay.

9) Sicherheit und Vertrauen

mTLS zwischen Knoten, Schlüsselpinning, Rotation.
Nachrichten/Webhook-Signaturen, Zeitstempel und Anti-Replay-Fenster.
Verschlüsselung unterwegs/in Ruhe; Segregation regionaler Schlüssel.
PII-Minimierung: Tokenisierung, Verbot personenbezogener Daten in Labels/Metriken.

10) Effizienz: Bündelung, Kompression, Cache

Batching: Gruppieren Sie kleine Nachrichten, um Overhead zu reduzieren.
Kompression: zstd/gzip mit sicheren Wörterbüchern.
Cache: negative Antworten und „heiße“ Verzeichnisse; TTL und Behinderung durch die Veranstaltung.

11) Datenschemata (Referenzen)

Register der Streams/Parties

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

Ereignisprotokoll (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/Quarantäne

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

12) Politik (YAML)

QoS und Limits

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

Finalisierung und Fenster

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

Routing/Wohnsitz

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

13) Beobachtbarkeit: SLI/SLO

• Latency p95/p99 (ingress→egress, per-stream/QoS).
• Success Rate / Drop Rate.
• Queue Lag p95 und consumer lag nach Parteien.
• Freshness p95 (ingest→consume).
• Reorg/Invalidated Rate (wenn onchain).
• Dedup Efficiency (% idempotent absorbierte Takes).
• Geo-Hit Ratio (lokal bedient).

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

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

14) Muster der Verbraucher

Outbox/Inbox: atomare Publikation und idempotente Anwendung.
Exactly-once-Effekt: Speichern Sie den zuletzt angewendeten Schlüssel und die Version.
Watermarks: Verarbeitung von verspäteten Ereignissen (Late Data).
Idempotent Side-Effects: Externe Abfragen nur mit Schlüssel und Antwortprotokoll.

15) Degradierungsregime

Finalized-only-Modus: Wir geben nur finalisierte Ereignisse aus.
Cache-only für Verzeichnisse, Einfrieren schwerer Methoden.
Throttle P2 und „Diät-Modus“ für Streams (reduzierte Aktualisierungsrate).
Nur für sekundäre APIs lesen.

16) Downtime-freie Releases und Migrationen

Blue-Green/Canary nach Streams und Consumern.
Schema-first: nur Felder hinzufügen; MAJOR sind parallele Versionen von Topics.
Offset-Migrationen: Schattenkonsumenten, Lag/Erfolg-Vergleich, Wechsel.

17) Betriebsvorschriften

Täglich: SLO-Bericht (Latenz/Erfolg/Lag/Frische), Unterschriftenprüfung, DLQ-Prüfung.
Wöchentlich: Revision der Parteien/Quoten, DR-Test (Bootstrap aus Snap-Shot), Analyse der Dedup-Effizienz.
Monatlich: Chaos-Tests (Loss/Jitter, Broker-Opt-out, Reorg-Burst), Überarbeitung der Finalitätsfenster.
Vor der Veröffentlichung: Kanarienvogel ≥120 min, SLO-Gates, Rollback-Plan.

18) Playbook der Vorfälle

A. Explosion von Queue-Lag/Consumer-Lag

1. Consumer/KEDA erhöhen; 2) Umverteilung der Parteien; 3) P2 und Bulk-Jobs einfrieren; 4) Analyse der „heißen“ Schlüssel.

B. Wachstum p95 Latency P0

1. P2-throttle, Priorisierung von P0; 2) skalieren Gateways/Broker; 3) Cache nur für Verzeichnisse; 4) outlier-ejection.

C. Hohe DLQ/Synchronisation

1. Idempotenz/TTL-Schlüssel prüfen; 2) Dedup verstärken; 3) Begrenzen Sie den lauten Produzenten; 4) Repliken nach dem Fix.

D. Drift von Regelungen/Verträgen

1. Strict-Modus aktivieren (Nicht-Valid abschneiden); 2) den Hersteller benachrichtigen; 3) den Adapter freigeben; 4) Aktualisieren Sie die Linter.

E. Verletzung des Wohnsitzes/der Unterschriften

1. Export-/Kanaleinheit; 2) Schlüssel-/Sert-Rotation; 3) Audit und Post-Mortem; 4) Aktualisierung der Richtlinien.

19) Checkliste Umsetzung

1. Definieren Sie die Thread-Typen und den Partitionierungsschlüssel.
2. Aktivieren Sie Idempotenz/Dedup und Finalisierung mit K/Spore-Fenstern.
3. Richten Sie Warteschlangen, QoS, Kontingente und Backpressure ein.
4. Führen Sie mTLS/Signaturen und Aufenthaltsrichtlinien aus.
5. Geben Sie Schemata/Register (Streams, Offsets, dlq) und SLI/SLO-Telemetrie ein.
6. Organisieren Sie Canary/Blue-Green und Migration von Schaltungen ohne Downtime.
7. Üben Sie degradierende Modi und Incident Playbooks.

20) Glossar

Backpressure - Steuerung der Eingangslast (Credits/Token/Limits).
DLQ ist eine „tote Warteschlange“ für problematische Nachrichten.
CRDT - Datenstrukturen mit Konfliktlösung ohne Koordination.
Finalität - Irreversibilität des Ereignisses/Zustands.
Exactly-once-Effekt - Wiederholungssicheres Ergebnis über at-least-once Lieferung.
Watermark - Markiert den Verarbeitungsfortschritt für spätere Ereignisse.
Outlier-ejection - Schließt degradierte Instances aus dem Pool aus.

Fazit: Die Datenströme zwischen den Knoten sind nicht nur „Warteschlange und Zuhörer“, sondern die Systemdisziplin von Ordnung, Finalisierung, Idempotenz, Sicherheit und Beobachtbarkeit. Standard-Partitionierungsschlüssel, QoS/Quoten, strenge Schemata und SLOs, zusammen mit degradierenden Modi und Playbooks, geben dem Ökosystem nachhaltige Datenkanäle auf der Skala und unter Kontrolle.