Регіональні хаби

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

1) Навіщо потрібні регіональні хаби

• Латентність і UX: близькість до користувача (RTT↓, TTI/TTF↓).
• Комплаєнс і резидентність: зберігання/обробка даних всередині юрисдикції.
• Стійкість і ємність: розвантаження глобального ядра, робота при частковій ізоляції регіону.
• Економіку: зниження міжрегіонального трафіку, локальні CDN/кеші, вигідні тарифи IX/peering.

2) Ролі регіонального хабу

1. Edge/Gateway - вхідний шар (HTTP/2/3, gRPC, WebSocket, QUIC), rate-limit, QoS, WAF.
2. Reader/API - RPC, індекси, пошукові сервіси, локальні materialized views.
3. Compute/Stream - обробка подій, агрегування, анти-фрод фільтри.
4. Data Plane - TSDB/колонічні вітрини, об'єктне сховище для «теплих» даних.
5. Compliance/KYC/KYB - локальні інтеграції з провайдерами і каталоги санкцій.
6. Payments/PSP - локальні методи оплати і он/офф-рамп.
7. Bridge/Relay - термінал міжчіпних повідомлень з локальним буфером фіналізації.
8. Observability - метрики/логи/трейси, синтетичні проби.
9. Governance/Access - каталоги ролей, ключів і лімітів для регіональних учасників.

3) Топології розгортання

Hub-and-Spoke: центральний «майстер-хаб» + регіональні споуки з частковою автономією.
Active–Active (Multi-Primary): симетрична робота декількох хабів з конфлікт-фрі реплікацією (CRDT/випереджаючі журнали).
Active–Passive: гарячий резерв з періодичною реплікацією і DR-ролловером.
Edge-Tiered: «тонкі» edge-вузли (CDN, WebSocket-фан-аут) → «товстий» регіональний хаб.

Вибір залежить від вимог до фіналізації/консистентності, вартості каналів і регуляторних обмежень.

4) Геомаршрутизація і політика резидентності

GeoDNS/Anycast + Latency-Aware LB: відправляємо запити в найближчий здоровий хаб.
Jurisdiction Routing: дані суб'єктів (EU/UK/TR тощо) залишаються у відповідному хабі; міжрегіональні пересилання - тільки за білими списками.
Traffic SOR (Smart Order Routing) для регіонів: враховує RTT, вартість каналу, комплаєнс-прапори, завантаження квот і SLO.
Fail-in-Place: при деградації зовнішніх зв'язків хаб продовжує обслуговувати «finalized-only» запити і локальні операції.

5) Дані: каталоги, реплікації, класи зберігань

• P0 - платежі/міст/ідентифікація (сувора резидентність, синхронізація «сигналів» тільки в агрегатах/хешів).
• P1 - продуктові події та агрегати (локальні в'ю + періодичний експорт).
• P2 - налагодження/логи (агресивна компресія, довга ретенція в регіоні).

• Події - лог-шипінг з порядком в межах партії (region-scoped keys).
• Сховища - асинхронна MMR/CRDT або snapshot-бекапи.
• Резидентність: політики DLP/PII, токенізація, роздільні ключі шифрування per-region.

6) Продуктивність і кешування

Кеші: edge-кеш (короткий TTL), read-through на API, negative cache.
Warm-data: останні N блоків/батчів, гарячі індекси за популярними методами.
DA/Batch-буфери для L2/мостів: локальна черга публікацій з підтвердженнями.
Hardware-Adjusted TPS: планування ємності по $/TPS і $/RPS з урахуванням регіональних цін.

7) QoS, черги і backpressure

Класи P0/P1/P2 на рівні шини і шлюзів; роздільні черги та квоти.
Partitioning: ключ'region'tenant'topic'для прогнозованого throughput.
DLQ: карантин «отруйних» повідомлень, ретраї з джиттером.
Admission Control: обмеження «дорогих» RPC (за діапазоном, фільтрами, лімітами).

8) SLI/SLO регіонального хабу

• p95 Latency (Edge/API), Success Rate, Queue-Lag p95, Freshness вітрин, Finality p95 (міст/релеї), Geo-Hit Ratio (частка запитів, обслужених в регіоні), Compliance Pass%.

• Edge/API p95 ≤ 350–450 мс, Availability ≥ 99. 95%.
• Freshness (P1) p95 ≤ 3 хв; Queue-Lag P0 p95 ≤ 2 с.
• Geo-Hit Ratio ≥ 85% (без міжрегіонального хопу).
• DR RTO ≤ 15 хв, RPO ≤ 5 хв для P0.

9) Спостережуваність і дашборди

Ops Core: latency/error/queue-lag/throughput за класами QoS.
Geo View: теплова карта RTT, Geo-Hit Ratio, міжрегіональний трафік.
Compliance: резидентність, санкційні хіти, експорт-логи.
Bridge/DA: фіналізація p95, challenge/reorg, відмови публікацій.
Capacity & Cost: TPS_per_$, CTS/1k запитів, Utilization%.

10) DR і стійкість

Резервні канали: незалежні IX/провайдери, шифровані тунелі міжхабових зв'язків.
Ізольований режим: «finalized-only», деградаційні API, локальні квитанції з подальшим reconcile.
Регулярні навчання: відключення трансатлантики, втрата DA/пруверів, «джиттер/втрати» на кордонах.

11) Економіка і планування ємності

CTS (Cost-to-Serve) per 1k ops: канали + обчислення + зберігання + ліцензії.
TPS_per_$: стійка пропускна здатність на 1 долар інфраструктури.
Peering/IX-оптимізація: локальні peer-точки, префікс-анонси, компресія і батчування.
Tier-модель: T1 (мін-набір сервісів), T2 (повнокровна аналітика), T3 (повний стек + DA/міст).

12) Референс-конфігурації

12. 1 політика маршрутизації (YAML)

yaml routing:
geodns:
regions: [eu, uk, tr, la, apac, na]
policies:
prefer_local: true fallback_chain: [nearest_healthy, master_hub]
compliance:
residency:
eu: ["eu"]
uk: ["uk"]
tr: ["tr"]
export_whitelist:
eu: ["anonymized_metrics","hash_anchors"]
slo_gates:
p0_latency_p95_ms: 400 queue_lag_p95_ms: 2000

12. 2 K8s: Edge-шлюз + HPA

yaml apiVersion: apps/v1 kind: Deployment metadata: { name: edge-gw, labels: { region: eu } }
spec:
replicas: 4 template:
spec:
containers:
- name: gw image: org/edge-gw:2. 7. 0 ports: [{ containerPort: 443 }]
env:
- { name: QOS_CLASSES, value: "P0,P1,P2" }
- { name: DENY_HEAVY_RANGE, value: "eth_getLogs>5000" }
apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: { name: edge-gw-hpa }
spec:
minReplicas: 4 maxReplicas: 24 metrics:
- type: Pods pods:
metric: { name: request_latency_p95_ms }
target: { type: AverageValue, averageValue: 350m }

12. 3 Kafka: партіонування по регіону/тентанту

yaml topic: "events. p0"
partitions: 96 config:
min. insync. replicas: 2 cleanup. policy: delete compression. type: zstd message. timestamp. type: CreateTime

12. 4 Політика резидентності та експортів

yaml data_policy:
pii: { tokenized: true, cross_region_export: "deny" }
exports:
anonymized_metrics: { allowed: ["eu","uk","na"], schedule: "5m" }
hash_anchors: { allowed: ["eu","uk","na","apac"], cadence: "15m" }

13) Схеми даних і запити

Каталог хабів і зв'язків

sql
CREATE TABLE hubs (
hub_id TEXT PRIMARY KEY,
region TEXT, tier SMALLINT, status TEXT,
rtt_ms INT, cost_per_1k_ops NUMERIC,
created_at TIMESTAMPTZ
);

CREATE TABLE interlinks (
src_hub TEXT, dst_hub TEXT,
capacity_mbps INT, cost_per_gb NUMERIC,
encrypted BOOLEAN, health TEXT,
PRIMARY KEY (src_hub, dst_hub)
);

Geo-Hit Ratio и Freshness

sql
SELECT region,
100. 0 SUM(CASE WHEN served_in_region THEN 1 ELSE 0 END)/COUNT() AS geo_hit_pct,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY freshness_s) AS freshness_p95
FROM req_stats
WHERE ts >= now() - INTERVAL '24 hours'
GROUP BY region;

TPS_per_$

sql
SELECT hub_id,
AVG(tps_sustained) / NULLIF(AVG(cost_usd_hour),0) AS tps_per_usd
FROM hub_perf
WHERE ts >= now() - INTERVAL '7 days'
GROUP BY hub_id;

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

Щодня: звіт SLO (latency/queue-lag/freshness), аудит експортів/резидентності, стан міжхабових ликів.
Щотижня: калібрування квот/QoS і GeoDNS, перерахунок CTS/TPS_per_$, ревізія кешів і «гарячих» індексів.
Щомісяця: DR-навчання (ізольований режим, перемикання каналів), перевірка DA/мостів.
Перед релізом: канарний rollout по одному хабу/регіону, SLO-гейти і план відкату.

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

A. Падіння міжрегіонального каналу

1. Перемкнути на резервний IX, включити стиснення/батчі;

2. Хаб в режим «finalized-only»;

3. Черга експортів - в буфер, з лімітом;

4. Комунікація з учасниками, пост-мортем.

B. локальна деградація API p95

1. Пріоритизувати P0, включити P2-throttle;

2. Збільшити репліки edge/API;

3. Включити кеш-тільки для гарячих методів;

4. Діагностика важких запитів, при необхідності deny-rules.

C. Порушення резидентності

1. Негайний блок крос-регіонального експорту;

2. Redaction/реверс експорту;

3. Повідомлення DPO/Compliance;

4. Оновлення політик і тестів.

D. піки reorg/DA відмов

1. Збільшити К/вікно спору;

2. Увімкнути «delayed finalization»;

3. Сповістити споживачів;

4. Доповнити звіти.

E. нерівномірне завантаження хабів

1. Перетюнінг GeoDNS/Latency-LB;

2. Баланс квот/цін;

3. Трафік-шейпінг для афіліатів/джерел.

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

1. Вибрати регіони/юрисдикції та цільові SLO.
2. Спроектувати топологію (Hub-Spoke або Active-Active), канали/IX.
3. Рознести ролі: Edge/API/Compute/Data/Bridge/Compliance.
4. Налаштувати резидентність, каталоги та експортні політики.
5. Увімкнути QoS, черги, кеші та backpressure.
6. Підняти спостережуваність і дашборди Geo/Compliance/Perf/Cost.
7. Налаштувати DR (RTO/RPO), навчання та ізольований режим.
8. Завести економічні метрики (CTS, TPS_per_$) і бюджет.

17) Глосарій

Geo-Hit Ratio - частка запитів, обслужених «своїм» хабом.
RPO/RTO - цілі по втраті даних/часу відновлення.
Hub-and-Spoke - центральний вузол з периферійними кластерами.
CRDT - структури даних для конфлікт-фрі реплікації.
CTS per 1k ops - вартість обслуговування 1000 операцій.
TPS_per_$ - пропускна здатність на долар інфраструктури.

Підсумок: регіональні хаби перетворюють глобальну мережу в набір локально оптимізованих, комплаєнтних і стійких доменів. При чітких SLO, резидентності, QoS і DR-процедурах вони знижують латентність і вартість, підвищують надійність і забезпечують масштабування екосистеми без втрати керованості.