Потоки даних між вузлами

(Розділ: Екосистема та Мережа)

1) Суть і цілі

• Передбачуваність: стабільні SLO по затримці/успіху/свіжості.
• Надійність: стійкість до втрат, дублікатів, реоргам.
• Безпека та комплаєнс: шифрування, підписи, резидентність.
• Масштабованість: гео-розподіл, партіонування, QoS.

2) Таксономія потоків

1. Control Plane: конфіги, фічефлаги, політики маршрутизації/лімітів.
2. Data Plane - подієві: доменні події ('deposit.','payout.','bridge.').
3. Data Plane - стрім: довгоживучі потоки (gRPC/WebSocket) для сигналів і live-метрик.
4. Batch/Backfill: завантаження історичних зрізів, реплеї, снапшоти.
5. Реплікація/анти-ентропія: state sync, мерклізація, CRDT-потоки.
6. Телееметрія/спостережуваність: логи/метрики/трейси side-band, не заважають основному UX.

Кожному типу відповідають класи QoS і власні правила ретраїв/порядку.

3) Топології та маршрутизація

Hub-and-Spoke: регіональні хаби як шини; споуки - вузли ролей.
Mesh/P2P: часткова ніздрюватість для реплікації/держсипу.
Edge-Tiered: тонкі edge-шлюзи (rate-limit/кеш) → товсті регіональні кластери.
Geo-Routing: Anycast/Latency-Aware LB + правила резидентності.

Ключове - партіонування: 'partition _ key = chainId'tenant'topic'entityId'дає передбачуваний порядок і масштаб.

4) Транспорт і формати

HTTP/2/3, gRPC/QUIC - низька латентність, мультиплексування, keepalive.
Kafka/Pulsar/NATS - черги з персистентністю/партіями/консьюмер-групами.
WebSocket - push-події та live-канали.
Формати: Protobuf/Avro (схеми з еволюцією), JSON для зовнішніх API.
Хеш-адресація і Merkle-квитанції для верифікації цілісності.

5) Порядок, доставка та фіналізація

• At-least-once (за замовчуванням; потрібна ідемпотентність/дедуп).
• Exactly-once-ефект через Outbox/Inbox + ідемпотентний консюмер.
• Порядок: гарантується в межах партії; міжпартиційний порядок не гарантується.
• Фіналізація: статусы `observed → confirmed(K) → finalized → invalidated(reorg)`; для optimistic - вікно спору.

6) Ідемпотентність і дедуп

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

• Upsert по ключу, TTL вікна дедупа ≥ 72 год.
• На конфлікт payload - політика «джерело істини» (пріоритет, версія, підпис).
• Для запитів HTTP - заголовок'Idempotency-Key'+ журнал відповідей.

7) Черги, backpressure і квоти

Черги: партії за ключем; DLQ для «отруйних» повідомлень.
Backpressure: кредити/токени, обмеження max-inflight, circuit-breaker.
Квоти/QoS: P0 (критичне), P1 (продукт), P2 (bulk). Роздільні пули/ліміти RPS/bytes/s/підписок.
Admission control: рання відмова «дорогих» запитів, guard за діапазонами/розмірами.

8) Узгодженість і моделі даних

Read-you-write в межах партії/вузла.
Eventual Consistency між регіонами/партіями.
CRDT для конфлікт-фрі реплікації деяких наборів (лічильники, множини).
Снапшоти + журнали для швидких bootstrap і детермінованого replay.

9) Безпека і довіра

mTLS між вузлами, пінінг ключів, ротація.
Підписи повідомлень/вебхуків, відмітка часу і анти-replay вікна.
Шифрування в дорозі/в спокої; сегрегація регіональних ключів.
PII-мінімізація: токенізація, заборона персональних даних в лейблах/метриках.

10) Ефективність: пакетування, компресія, кеш

Batching: групування дрібних повідомлень для зниження overhead.
Compression: zstd/gzip з безпечними словниками.
Кеш: негативні відповіді та «гарячі» довідники; TTL та інвалідація за подією.

11) Схеми даних (референси)

Регістр потоків/партій

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

Журнал подій (ідемпотентний 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/карантин

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

12) Політики (YAML)

QoS і ліміти

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

Фіналізація та вікна

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

Роутинг/резидентність

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

13) Спостережуваність: SLI/SLO

• Latency p95/p99 (ingress→egress, per-stream/QoS).
• Success Rate / Drop Rate.
• Queue Lag p95 і consumer lag по партіях.
• Freshness p95 (ingest→consume).
• Reorg/Invalidated Rate (якщо ончейн).
• Dedup Efficiency (% дублів, поглинених ідемпотентно).
• Geo-Hit Ratio (обслуговується локально).

• P0 latency p95 ≤ 400 мс; Success ≥ 99. 95%; Queue-lag p95 ≤ 2 с; Freshness p95 ≤ 60 с.
• Dedup efficiency ≥ 99%; DLQ ≤ 0. 1% від трафіку.

Дашборди: Streams Core / Lag & Freshness / QoS & Errors / Geo / Security (mTLS/подписи).

14) Патерни споживачів

Outbox/Inbox: атомарна публікація та ідемпотентне застосування.
Exactly-once-ефект: зберігати останній застосований ключ і версію.
Watermarks: обробка запізнюючих подій (late data).
Idempotent Side-Effects: зовнішні запити тільки з ключем і журналом відповідей.

15) Деградаційні режими

Finalized-only mode: видаємо тільки фіналізовані події.
Cache-only для довідників, заморожування важких методів.
Throttle P2 і «режим дієти» для стрімів (знижена частота оновлень).
Read-only для другорядних API.

16) Релізи та міграції без даунтайму

Blue-Green/Canary по потоках і консьюмерів.
Schema-first: тільки додавання полів; MAJOR - паралельні версії топіків.
Міграції offset'ів: shadow-консьюмери, порівняння lag/успіху, перемикання.

17) Операційні регламенти

Щодня: звіт SLO (latency/success/lag/freshness), аудит підписів, перевірка DLQ.
Щотижня: ревізія партій/квот, тест DR (bootstrap зі снапшота), аналіз Dedup Efficiency.
Щомісяця: chaos-тести (loss/jitter, відмова брокера, reorg-бурст), перегляд finality-вікон.
Перед релізом: канарка ≥120 хв, SLO-гейти, план відкату.

18) Playbook інцидентів

A. Вибух Queue-Lag/Consumer-Lag

1. Збільшити консьюмерів/KEDA; 2) перерозподілити партії; 3) заморозити P2 і bulk-джоби; 4) аналіз «гарячих» ключів.

B. зростання p95 Latency P0

1. P2-throttle, пріоритизація P0; 2) масштабувати шлюзи/брокери; 3) кеш-тільки для довідників; 4) outlier-ejection.

C. високий DLQ/дубляж

1. Перевірити ключ ідемпотентності/TTL; 2) посилити дедуп; 3) обмежити галасливого продюсера; 4) реплей після фіксу.

D. drift схем/контрактів

1. Увімкнути strict-mode (відсікати невалідні); 2) повідомити продюсера; 3) випустити адаптер; 4) оновити лінтери.

E. Порушення резидентності/підписів

1. Блок експорту/каналу; 2) ротація ключів/сертів; 3) аудит і пост-мортем; 4) оновлення політик.

19) Чек-лист впровадження

1. Визначте типи потоків і ключ партіонування.
2. Увімкніть ідемпотентність/дедуп і фіналізацію з вікнами К/спору.
3. Налаштуйте черги, QoS, квоти та backpressure.
4. Запустіть mTLS/підписи і політику резидентності.
5. Введіть схеми/реєстри (streams, offsets, dlq) і телеметрію SLI/SLO.
6. Організуйте canary/blue-green і міграції схем без даунтайму.
7. Відпрацюйте деградаційні режими та плейбуки інцидентів.

20) Глосарій

Backpressure - контроль вхідного навантаження (кредити/токени/ліміти).
DLQ - «мертва черга» для проблемних повідомлень.
CRDT - структури даних з вирішенням конфліктів без координації.
Finality - незворотність події/стану.
Exactly-once-ефект - повтор-безпечний результат поверх at-least-once доставки.
Watermark - відмітка прогресу обробки для пізніх подій.
Outlier-ejection - виключення деградованих інстансів з пулу.

Підсумок: потоки даних між вузлами - це не просто «черга і слухач», а системна дисципліна порядку, фіналізації, ідемпотентності, безпеки і спостережуваності. Стандартні ключі партіонування, QoS/квоти, строгі схеми і SLO, разом з деградаційними режимами і плейбуками, дають екосистемі стійкі канали передачі даних на масштабі і під аудит.