Горизонтальне розширення мережі

1) Навіщо горизонтально розширювати мережу

Горизонтальне розширення (scale-out) - додавання паралельних вузлів/каналів замість «накачування» одного потужного сервера або єдиного каналу зв'язку. Для iGaming це критично: піки лайв-ставок, турніри і великі релізи провайдерів вимагають передбачуваної латентності, високої доступності і еластичності без простою.

• Стабільна p95-латентність при N × навантаженні.
• Відсутність єдиної точки відмови (SPOF).
• Економіка: лінійне зростання пропускної здатності при обмеженому зростанні витрат.

2) Базові принципи scale-out

1. Stateless-сервіси на периферії: авторизація по токенах, idempotency-ключі, sticky-routing тільки там, де необхідно.
2. Шардинг і партіонування: розподіл користувачів/подій/трафіку за сегментами.
3. Horizontal first для мережевих компонентів: L4/L7 балансувальники, проксі, брокери, кеші.
4. Політики повторів/таймаутів і зворотний тиск (backpressure).
5. Спостережуваність і SLO як зворотний зв'язок для авто-масштабування.
6. Zero Trust і мікросегментація - безпека зростає разом з кількістю вузлів.

3) Мережеві патерни масштабування

3. 1 Глобальний рівень (GSLB/Anycast)

GSLB розподіляє користувачів по регіонах (EU, LATAM, APAC) за метриками латентності/здоров'я.
Anycast-адреси для вхідних точок (DNS, API, WebSocket), швидкий фейловер BGP.
Geo-policies: облік локалізації даних і правил доступу до провайдерів/платежів.

3. 2 Регіональний рівень (L4/L7)

L4-балансувальники (ECMP, Maglev-подібні хеші) → рівномірний розподільник конектів.
L7-шлюзи/WAF: маршрутизація по шляху/версії/тенантам, rate limiting, анти-бот.
Service Mesh: circuit-breaker, retries з джиттером, outlier-ejection.

3. 3 East-West трафік (всередині кластера/ЦОДа)

Spine–Leaf fabric + ECMP: передбачувані затримки.
Sidecar-проксі для mTLS, телеметрії і керованих політик.
Квоти/ліміти на сервіс і неймспейс для захисту від «галасливих сусідів».

4) Горизонтальне масштабування даних

4. 1 Кеші

Багаторівневі кеші: CDN/edge → L7-кеш → Redis/в-процесі.
Консистентний хеш для розподілу ключів, реплікація на N вузлів.
TTL і шари догріву (warming) перед великими івентами.

4. 2 Брокери подій (Kafka/совм.)

Шардування по ключу (playerId, sessionId) → порядок всередині партії.
Збільшення партій лінійно підвищує пропускну здатність споживачів.
Quota/layered topics для різних доменів: ставки, платежі, KYC, ігри.

4. 3 OLTP/OLAP

CQRS: запис/команди окремо від читань/запитів.
Read-репліки для масштабування читання; шардинг для масштабування запису.
Регіональна ізоляція даних + асинхронна реплікація в дозволені юрисдикції.

5) Сесії та стан

Stateless-JWT/opaque-токени з коротким TTL і ротацією.
Sticky-sessions тільки для потоків, де потрібен локальний стан (наприклад, live-стіл).
Idempotency-ключі на рівні API/гаманця для безпечних повторів.
Дедуплікація подій (exactly-once в бізнес-сенсі через ключі/саги).

6) Управління сплесками (Peak Readiness)

Token Bucket/Leaky Bucket на L7-шлюзі і в меш-політиках.
Буферизація/черги перед «крихкими» апстрімами (KYC, PSP).
Авто-масштабування за метриками: rps, p95, CPU, lag брокера, довжина черг.
Fail-open/fail-closed стратегії (наприклад, деградація не-критичних фіч).

7) Безпека при scale-out

Zero Trust: mTLS між усіма сервісами, короткоживучі сертифікати.
Мікросегментація: окремі мережі для prod/stage/vendors/payments.
Підпис S2S (HMAC/JWS), строгий egress-контроль, DLP/CASB.
Ротація ключів/секретів автоматизована (KMS, Vault), наскрізний аудит.

8) Спостережуваність і SLO-управління

Логи/метрики/трейси + профайлінг (в т.ч. eBPF).
SLO: p95-латентність логіну/депозиту/ставки/спіну, успішність платежів, доступність регіонів.
Алертинг по бюджету помилок, не по «голих» метриках.
Топологічна карта залежностей для RCA і планування capacity.

9) Відмовостійкість і DR при горизонтальному зростанні

Active-Active для автентифікації та гаманця, Active-Standby для важких stateful.
GSLB/BGP-фейловер з цілями <30-90 сек.
Chaos-інжиніринг: відключення зон/партій/PSP на стейджі і періодично - у проді за регламентом.
Black-start-шлях: мінімальний набір сервісів для підйому екосистеми.

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

Baseline: нормальна доба + x3/x5 «ніч фіналу ЛЧ».
Headroom: 30-50% вільної потужності в критичних доменах.
Unit-economics: вартість rps/топіка/сесії, ціна одного GSLB-регіон-фейловера.
Авто-вимикання зайвих вузлів поза піками, фінанси ≈ контроль SLO.

11) Типові архітектурні схеми

A) Глобальна вітрина і API

GSLB (latency-based) → L4 балансери (ECMP) → L7 шлюзи/WAF → Mesh сервісів → Redis-кеш → Kafka → OLTP-шарди/репліки → OLAP/даталейк.

B) Live-ігри/Live-ставки (низька затримка)

Anycast вхід → регіональні PoP з WebRTC/QUIC → пріоритетні канали до RGS → sticky тільки для столу/сесії → локальні кеші і швидкі health-flip.

C) Платіжний периметр

Ізольований сегмент + оркестратор PSP → черги/ретраї з ідемпотентністю → кілька провайдерів з пріоритизацією і cut-over по SLI.

12) Анти-патерни

Єдиний L7-шлюз без горизонтального масштабування.
Загальна сесія в кеш-кластері без TTL/ізоляції тенантів.
Безконтрольні ретраї → шторм трафіку і «аноміка» апстріму.
Глобальні транзакції через кілька регіонів в real-time.
Реплікація ПДн в «заборонені» регіони заради аналітики.
Автоскейл по CPU без кореляції з p95/чергами/lag.

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

1. Визначити домени і SLO, де потрібна горизонтальна еластичність.
2. Ввести GSLB і консистентний хеш на L4, L7-маршрутизацію за версією/тенанту.
3. Перевести зовнішні API на stateless + idempotency, мінімізувати sticky.
4. Налаштувати кеш-шари і брокер подій з партіонуванням по ключах.
5. Спроектувати шардинг OLTP і read-репліки, відокремити OLAP (CQRS).
6. Увімкнути rate limiting, backpressure, черги перед зовнішніми провайдерами.
7. Автоматизувати HPA/VPA за composite-метриками (p95, rps, lag).
8. Розгорнути спостережуваність, алерти по бюджету помилок, топокарту.
9. Регулярні DR-навчання і chaos-сценарії, перевірка Black-start.
10. Вбудувати Security-by-design: mTLS, egress-контроль, ротація секретів.

14) Метрики здоров'я та контролю масштабу

p95/p99 для логіну/депозиту/ставки/спіну.
Рівень помилок на L7-шлюзі і в mesh (5xx/429/timeout).
Lag брокера і глибина черг, час обробки подій.
Hit-ratio кешів, пропускна здатність сховищ.
Доступність регіонів/РоР, час GSLB/BGP-перемикань.
Cost per rps і утилізація вузлів.

15) Дорожня карта еволюції

v1: GSLB + L4 ECMP, статичний autoscale, кеш-шар.
v2: Політики міша (retries/circuit-breaker), брокер подій, read-репліки.
v3: Шардінг OLTP, актив-актив для критичних доменів, адаптивний autoscale по SLO.
v4: Автономні домени (Data Mesh), предиктивний capacity, автотюнінг маршрутів.

Коротке резюме

Горизонтальне розширення мережі - це системна дисципліна: stateless-ядро, шардинг даних і подій, багаторівневе балансування (GSLB/L4/L7/mesh), кеші і черги для сплесків, плюс SLO-управління, Zero Trust і DR-практики. При такому підході екосистема iGaming витримує світові піки трафіку, залишається законослухняною в різних юрисдикціях і масштабується майже лінійно в міру зростання аудиторії.