22:07. Прем’єра серіалу. Кнопка «Play» — і крива трафіку злітає. За хвилину — ще ×8. Система живе на кеші. У черзі — тисячі запитів. Першими стогнуть сесії та пошук. Через три хвилини доїдає ліміти API платежів. Якщо нема плану, усе лягає каскадом.
Картина схожа у ставках на топ‑матч. Кожна секунда — гроші. Затримка у 300 мс — і ставка вже не та. Без ідемпотентних подій і жорстких лімітів хаос росте. У соціальному лайві інша пастка: тисячі мікро‑подій (лайки, подарунки) душать бекенд метриками високої кардинальності.
Цей текст — для CTO, CPO, SRE та архітекторів, які готують платформи розваг до піку. Будуть реальні патерни, антипатерни, цифри, таблиця, і 90‑денний план.
Профіль трафіку не рівний. Він «б’є хвилями». Є короткий бурст ×10–×20 на 10–20 хв. Є плато на 2–3 години. Є довга «коса» фонового трафіку. Користувачі приходять з усього світу. Кеш рятує, але не вічно. Балансер має бачити гео і здоров’я сервісів.
Цілі прості на словах, жорсткі на ділі: P95 до 150–250 мс у регіоні, P99 до 400–600 мс; 99.9–99.99% доступності; чіткий бюджет помилок. Це класика підходу SRE і роботи зі SLO — докладно описано у книзі Google про SRE: підхід SRE та SLO.
Сучасна платформа — це CDN/edge, глобальний балансер, мультірегіон, Kubernetes з автоскейлом, події (Kafka), кілька шарів кешу, фінансові сервіси з точною послідовністю. Поради по внутрішній інженерії добре зібрані у AWS Builders Library.
Бурст трафіку — ×10–×20 за хвилини. Рятує CDN. Прогрівати edge до старту. Відео йде адаптивно (ABR). Вміст кешується близько до глядача. Початковий маніфест і ключі DRM — у гарячому кеші. Бекенд бачить тільки auth і нетипові запити.
Перед стартом — «суха репетиція» з синтетичним трафіком. Якщо P95 росте — збільшуємо warm‑pool нод, готуємо rate‑limits на API. Досвід гігантів добре описує Netflix TechBlog. Ключ: менше стани на бекенді, більше на клієнті та в edge.
Критично мало затримки в оновленні коефіцієнтів. Події з полів ідуть у Kafka. Прайсинг — окремо. Ставка — транзакція з ідемпотентним ключем. Схема «exactly‑once» для грошей. Будь‑який повтор — не має подвоювати виплату. Антиботи фільтрують спайки, WAF ріже «пилососи». Сесії тримати не липкими; стан — у Redis або подіях.
Тут маркетинг іде хвилями. Юзери одночасно шукають, де грати. Часто вони відкривають огляди та порівняння. Саме в такі хвилини корисно мати прогріті промо‑сторінки і ввімкнений тротлінг на «важкі» блоки. Якщо ви даєте довідку про ліцензії та ліміти гри, дайте її поруч. Для прикладу, огляди й освітні матеріали є на ebgt.info (азартні ігри — 21+, грайте відповідально). Це не про заклик, а про прозору інформацію для дорослих користувачів.
Тут болить не одне велике відео, а тисячі дрібних подій: подарунки, реакції, чати. Вони створюють шквал запитів до бекенду та баз моніторингу. Краще збирати їх у черги та батчити. На edge можна ставити «кімнату очікування» для великих прем’єр — як у Cloudflare Waiting Room. Так ви тримаєте досвід стабільним під час бурсту.
Немає однієї схеми «на всі випадки». Нижче — карта, яка допоможе зорієнтуватись за 5 хвилин. Перед читанням перевірте ваші граничні SLO і ліміти провайдерів.
| Стрімінг прем’єри | ×10–×20 на 10–20 хв; глобально | 150–250 мс / 400–600 мс | CDN/edge, глобальний LB, K8s | Статус у клієнті; мінімум стану | HPA + warm‑pool; rate limits | TTL 60–120 с; прогрів; маніфести в кеші | Error budget, saturation, 5xx | Холодний кеш; API‑квоти DRM | GDPR, антиботи, WAF | CDN offload, reserved інстанси |
| Лайв‑беттінг | ×5–×12 під час матчу; регіонально | 80–150 мс / 250–400 мс | Kafka, Redis, мультірегіон | Event‑sourcing; ідемпотентність | Karpenter/HPA; жорсткий тротлінг | Короткий TTL; інвалідація за подією | P50/P95 латентність, queue lag | Дубль ставок; ліміти платіжних API | PCI DSS, KYC/AML, WAF | Кеш коефіцієнтів, storage class |
| Лайв‑івент/соціальний | ×3–×8 бурсти; спалахи дрібних подій | 120–200 мс / 350–500 мс | Edge фільтри, черги, LB | Агрегація, батчинг | Backpressure; квоти на події | Кеш API‑відповідей 30–60 с | Cardinality метрик, RPS | High‑cardinality; DDoS шар | GDPR, SOC 2 | Cloud‑сейвінг плани, CDN |
Щоб автоскейл не «запізнювався», перегляньте HPA в Kubernetes. Для потоків грошей корисні «exactly‑once» підходи у Kafka — дивіться розбір від Confluent: як Kafka робить exactly‑once.
Автоматизовані загрози ростуть у пік. Скрейпери, боти, карт‑тестинг. Почніть із WAF і керування ботами. Список типових атак — у OWASP Automated Threats. Далі — сегментація, принцип найменших прав, секрети у менеджері секретів.
Комплаєнс — це стримувач хаосу. PCI DSS 4.0 для карткових даних: офіційні матеріали PCI. Для персональних даних — GDPR. Для довіри партнерів — SOC 2 та ISO 27001. Для хмари — матриця контролів CSA CCM.
Для гемблінгу діють KYC/AML і вікові обмеження. Будьте чіткі: 21+ в Україні. Додайте блок «відповідальна гра». Якщо на довідковій сторінці є перелік ліцензій і політик, посилайтеся на нього поруч із промо. Прикладом може бути нейтральна довідка на ebgt.info (без агресивних закликів).
80% економії дає просте: більше кешу на edge, правильний storage class, підбір типів інстансів. CDN offload інколи знімає 40–70% трафіку з бекенду. Те, що не потрібно в реальному часі, відправляйте у черги.
Бюджет має слухати SLO. Якщо SLO по P95 — 200 мс, не варто платити за 100 мс, якщо це не дає бізнес‑вигоди. Вимірюйте вартість на запит, на хвилину відео, на ставку. Культура й інструменти — на FinOps Foundation.
Обережно з «знижками». Reserved/Savings плани — лише для стабільних сервісів. Для піків — спот/авто підйом і падіння. Логи та метрики — з ретенцією за класами.
Чим HPA відрізняється від Karpenter? HPA масштабує поди за метриками. Karpenter — ноди під ваші поди. Разом вони швидше ловлять бурст.
Active‑active чи active‑passive? Для критичних піків — active‑active. Дорожче, але швидше. Для другорядних сервісів — active‑passive з чітким RTO/RPO.
Як планувати пік + DDoS? Edge‑фільтри, WAF, бот‑менеджмент, квоти. Залишайте запас у CDN і балансері. Прогрівайте кеш до старту.
Що робити з холодним стартом функцій? Тримайте «теплі» екземпляри на пікових маршрутах. Критичну логіку — у довгоживучих сервісах, не у функціях.
Моніторинг з’їв бюджет? Зменшити кардинальність, обрізати ретенцію, зберігати сирі логи в холодному сховищі, робити семплінг трейсів.
Було: бекенд витримував до 15 тис. RPS, P99 — 900 мс у бурсті. Каса впиралась у 1 000 req/s на под, HPA розганявся запізно, кеш на edge — холодний.
Що зробили за тиждень: прогріли CDN, TTL маніфестів — 120 с, ввели warm‑pool на 20% кластера, додали ключі ідемпотентності, в Kafka поставили батчі. У платіжного провайдера підняли квоти на 3 години. Вимкнули 5 висококардинальних лейблів.
Стало: той самий бурст — P95 170 мс, P99 430 мс. Каса — без черг. 5xx — мінус 72%. Вартість на запит — мінус 28% завдяки CDN offload.
Автор: Інженер з хмари та SRE. 8+ років у стрімінгу, гемблінгу, соціальних івентах. Сертифікації: AWS, GCP, Kubernetes.
Оновлено: 05/2026
У тексті є посилання на сторонні ресурси: Netflix TechBlog, AWS Builders Library, книга SRE та інші. Партнерські/афілійовані — позначені як nofollow/sponsored. Для азартних ігор діє правило 21+, грайте відповідально.