Потоки данных между узлами

(Раздел: Экосистема и Сеть)

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. Включите идемпотентность/дедуп и финализацию с окнами K/спора.
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, вместе с деградационными режимами и плейбуками, дают экосистеме устойчивые каналы передачи данных на масштабе и под аудит.