Крос-регіональне масштабування

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

1) Навіщо це потрібно

• зниження затримок і підвищення QoE (latency-driven routing),
• відмовостійкості на рівні регіону (disaster class),
• дотримання локальних вимог (локалізація даних, комплаєнс),
• еластичності під сплески трафіку і сезонність,
• незалежних релізних циклів і експериментів в окремих зонах.

2) Цільові SLO і базові принципи

Latency бюджет: p95/p99 для ключових шляхів (авторизація, платежі, ігрові раунди, вебхуки).
Availability: ≥ 99. 9% на регіон і ≥ 99. 95% на глобальну площину.
Consistency by design: явний вибір моделей RPO/RTO і рівня узгодженості по доменах.
Idempotency/Exactly-once-semantics: на кордонах між регіонами.
Observability: наскрізні трасування і кореляція подій між регіонами.

3) Моделі розміщення і трафіку

A. active-active (multi-master читання/запис)

Плюси: мінімальна затримка, горизонтальна масштабованість, м'які фейловери.
Мінуси: складність конфлікт-резолюції, зростання вартості.

B. Active-Passive (cold/warm standby)

Плюси: простіше реалізація, передбачувана цілісність.
Мінуси: підвищена затримка для віддалених користувачів, час перемикання.

C. Active-Read Replica (hybrid)

Плюси: локальні швидкі читання, контрольна точка консистентності в одному регіоні.
Мінуси: реплікація з лагом; запис центральний.

4) Мережева площина і маршрутизація

GSLB/GeoDNS/Anycast: направляє користувача в найближчий здоровий регіон.
Health-проби та вагові політики: latency-aware, capacity-aware, cost-aware.
Edge/PoP вузли: TLS-термінація, WAF, rate-limits, кешування статики та API-відповідей.
Внутрішня зв'язність: приватні міжрегіонні канали, egress-контроль, Zero Trust.

5) Дані: стратегії узгодженості

• Strong (платіжні транзакції, баланси, ліміти): єдиний лідер, «write-through» в майстер-регіон, синхронні інваріанти.
• Timeline/Session (ігрові події, телеметрія): асинхронна реплікація, upsert/append-only.
• Catalog/Reference (контент, конфігурації): multi-region кеш + м'яка консистентність.

• Sharding по регіону/тенанту, Multi-primary з CRDT/замиканням предметної області, Outbox/Transaction log для надійної публікації подій.

6) Подієва шина і черги

Federated event bus: локальні кластери (наприклад, «регіональні топіки») + міжрегіональна реплікація.
Ordering по ключу (player_id, transaction_id) для детермінованої обробки.
Replay/Backfill: зберігання журналу подій, дедуплікація по message-key.
Dead-letter/Retry політики: експоненційний backoff, poison-message карантин.

7) Кешування та узгодження покриттів

Tier-кеш: L1 (процес), L2 (регіон), L3 (edge).
Invalidation: по ключу і по топіках змін (pub/sub-інвалідації).
Stale-while-revalidate: для довідників і контенту.
Cache keys з регіоном і версією схеми для уникнення колізій.

8) Ідентифікація, сесії та маршрутизація по користувачеві

Sticky-routing по user_id/tenant_id, щоб мінімізувати міжрегіональні переходи.
Глобальні ID: високоентропійні, сортовані (ULID/KSUID), що включають регіональні префікси для діагностики.
Сесії: регіональні + загальний рефреш-контур (OIDC), пере-аутентифікація при міграції.

9) Безпека та комплаєнс

Локалізація даних: персональні та фінансові дані в «зоні довіри» відповідного регіону.
Криптографія: KMS з регіональною сегрегацією ключів, чітка ротація і «envelope encryption».
Сегментація мережі: принцип найменших привілеїв, сервіс-акаунти з регіональними ролями.
Аудит: незмінні логи, трасування доступу до PII/PCI.

10) Спостережуваність і управління інцидентами

Наскрізні трасування: глобальні trace-id, пропагандація контексту через шину подій.
Метрики та алерти: окремі SLO per-region і агреговані глобальні; альберти з контекстом «який регіон деградує».
Дашборди «латентність/помилки/навантаження»: p50/p95/p99, saturation, черги, лаг реплікації.
Chaos & GameDays: регіональні відключення, уповільнення каналів, уцінка ємності.

11) Розгортання та версії

Regional Blue-Green/Canary: незалежні викати з обмеженням blast-radius.
Feature-flags з гео-таргетингом: по регіонах і сегментах трафіку.
Schema evolution: двонаправлена сумісність (backward/forward), «expand-migrate-contract».

12) Економіка та управління витратами

Capacity-planning: за годинами/днями/сезонами; буфери під пікові події.
Cost routing: гібридні політики (якщо два регіони рівні за затримкою - вибираємо дешевший).
Egress-оптимізація: локальна агрегація/стиснення, дедуплікація, кеш-хіти.
Unit-economics: вартість запиту/ігрового раунду/транзакції по регіонах.

13) Ризики та анти-патерни

«Єдина глобальна правда» для всього домену → надлишкові міжрегіональні синхронізації.
Приховані міжрегіональні залежності (читання чужого індексу/кешу).
Відсутність регіональних лімітів і circuit-breakers.
Неузгоджені версії схем/протоколів між регіонами.

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

1. Визначити домени і вимоги до консистентності (Strong/Eventual).
2. Вибрати модель (Active-Active/Active-Passive/Hybrid) по доменах.
3. Спроектувати маршрутизацію (GSLB, health-перевірки, sticky-policies).
4. Спроектувати зберігання (шардинг, реплікація, outbox).
5. Ввести idempotency-ключі та дедуплікацію.
6. Побудувати observability (traces/metrics/logs) з глобальними кореляторами.
7. Налаштувати комплаєнс і локалізацію даних.
8. Автоматизувати DR-дні і регулярні failover-тренування.
9. Запровадити економічні метрики та бюджетні гвард-рейли.
10. Каталогувати SLO/помилки/інциденти по регіонах.

15) Типовий референс-патерн

Edge шар: Anycast + WAF + глобальний кеш.
API-шлюз per-region: авторизація, квоти, маршрути.
Сервісний шар: мікросервіси з локальними БД і регіональними чергами.
Дані: майстер-регіон для критичних записів; регіональні репліки/шардові кластери.
Події: локальні топіки, реплікація міжрегіональними конекторами; дедуп на споживачах.
Observability: уніфікована телеметрія, глобальні trace-id.

16) Застосування для iGaming/фінтех-екосистем

Ігрові раунди: локальна обробка з гарантією фіксації результату в майстер-домейні.
Платежі та KYC: сувора консистентність, регіональні «зони довіри».
Промо і контент: агресивне кешування + SWR, edge-інвалідації.
Вебхукі партнерам: черги з ретраями, гарантія доставки (at-least-once + ідемпотентність на приймачі).

17) KPI і метрики здоров'я

p95 latency за ключовими шляхами в кожному регіоні і глобально.
Рівень помилок 4xx/5xx, частка кеш-хітів, лаг реплікації.
Час DR-перемикання, частота успішних DR-тренувань.
Вартість на 1k запитів по регіонах, egress/ingress на вузол.

18) План еволюції (ітерації)

1. Phase-0: один регіон + edge-кеш.
2. Phase-1: другий регіон як read-replica, GSLB.
3. Phase-2: гібридний запис (часткові домени Active-Active).
4. Phase-3: повноформатний Active-Active для latency-критичних доменів, автономні релізи.

19) FAQ

Чи можна скрізь зробити Active-Active? Не потрібно. Діліть домени по консистентності та економіці.
Як боротися з конфліктами запису? CRDT/версіонування/песимістичні ліз-локи, детерміновані правила мерджа.
Що з legal-вимогами? Зберігайте PII/фіндані в регіональних «зонах довіри», анонімізуйте та агрегуйте для міжрегіональної аналітики.
Як тестувати? Регулярні GameDays: ізоляція регіону, деградація каналів, масові ретраї.

Коротке резюме: крос-регіональне масштабування - це не «магічна кнопка», а набір дисциплін: правильна маршрутизація, доменна сегрегація даних і подій, сувора телеметрія, керована консистентність і економічний контроль. Діліть систему на домени, підбирайте модель під кожен домен і автоматизуйте навчання команди через регулярні DR-вправи.