Технології та Інфраструктура → CDN-мережі та кешування контенту

CDN-мережі та кешування контенту

1) Навіщо CDN і кеш

• Швидкий перший байт для каталогу, асетів, промо, медіа.
• Пікова стійкість (турніри/івенти) без вибухового зростання origin-потужностей.
• Економія egress і передбачувана вартість.
• Гео-контроль (регуляторика, ліцензування контенту).

2) Базові стратегії кешування

2. 1 Відповіді, які можна кешувати

Статика: JS/CSS/шрифти/іконки - довгі TTL (30-365 днів) + file-hash в імені.
Напівстатика: каталоги ігор, банери, конфіги - TTL від хвилин до годин +'stale-while-revalidate'.
API GET/HEAD: довідники, прайсинг, лідерборди - короткі TTL (5-120 сек) з коректним ключем.

2. 2 Заголовки

`Cache-Control: public, max-age=600, stale-while-revalidate=300, stale-if-error=600`

'ETag '/' Last-Modified'для умовних запитів (revalidation).
'Surrogate-Control '/' CDN-Cache-Control'( якщо провайдер підтримує).
Для приватних даних: `Cache-Control: no-store'( а не просто'no-cache').

2. 3 Ключ кешу (cache key)

Базово: метод + URL-шлях + query-параметри, що впливають на відповідь.
Добавки: 'Accept-Encoding'( gzip/br),'Accept'( json/webp/avif), локаль ('Accept-Language'), регіон/валюта, якщо впливає на контент.
Уникайте потрапляння в ключ випадкових заголовків (cookies, trace ids).

3) Управління Vary і кукі

`Vary: Accept-Encoding, Accept, Accept-Language'- мінімально необхідний набір.
Стрипінг cookie на CDN для кешованих шляхів: прибираємо все, крім whitelisted (напр. AB-прапорів).
Перенесення session-ідентифікаторів в піддомени/шляхи поза кешованим контентом.

4) Патерни TTL і свіжості

Immutable статика: `Cache-Control: public, max-age = 31536000, immutable'+ версії в імені файлу.
SWRO/SIE: 'stale-while-revalidate'і'stale-if-error'- UX-стійкість при проблемах у origin.
Partitioned TTL: кореневий список ігор - 30-60 сек; картка гри - 5-10 хв; банери - 30 хв.
API мікс: базові довідники - 5-30 хв; валюти/ліміти - 1-5 хв; лідерборд ― 2-15 сек.

5) Tiered caching и origin shield

Tiered/Regional caches: запити, що пройшли повз edge, б'ються в регіональний «shield» замість origin.
Переваги: менше MISS на origin, згладжування «штормів», дешевше egress.
Щити групуйте за гео з найбільшою щільністю трафіку (EU, TR, BR, LATAM).

6) Інвалідація та прогрів

Purge by path/prefix/tag: теги зручні для пакетного очищення (реліз каталогу, промо-кампанія).
Soft purge (grace): позначаємо контент застарілим, але віддаємо до приходу нового.
Прогрів (prewarm): сценарії при релізі/перед турніром: опитування популярних шляхів, генерація спрайтів і варіацій картинок.
Канарська інвалідація: чистимо частково, валідуємо метрики/помилки, потім розширюємо.

7) Edge-правила і функції (Workers/Functions)

Перезапис відповідей: додавання заголовків кеша, нормалізація'Vary', стрипінг cookies.
Geo/ASN-роутинг: редиректи, локаль/валюта по країні.
Підпис URL (Signed URLs/Headers) для захищеного медіа/об'єктів.
Edge-AB-тести: легкі, без зростання навантаження на origin (тільки для статик/напівстатик).
Edge-compute: рендер легких віджетів/персоналізації, але не гарячий платіжний шлях.

8) Зображення та відео

8. 1 Картинки

Автоконверсія: WebP/AVIF при'Accept'клієнта;'Vary: Accept`.
Ресайзинг на edge: параметри'w/h/fit/quality'; готуйте пресети (картка, банер, прев'ю).
Спрайти і SVG-оптимізація, lazy-loading на фронті.

8. 2 Відео/стрім

HLS/DASH з короткими сегментами (2-4 сек), що перекриваються плейлисти.
Preload найближчих сегментів і'stale-if-error'.
Для live-ставок - тримайте сегменти в регіональному shield для скорочення TTFB.

9) API через CDN

Кешовані GET: додайте'Cache-Control'і коректний ключ (локаль/валюта/регіон).
Conditional GET: 'ETag '/' If-None-Match'знижує байти і TTFB.
POST/PUT: не кешуються; можна кешувати відповіді POST тільки при явних правилах і ідемпотентній семантиці (рідко виправдано).
Rate limiting/WAF на краю: знижує хвости за рахунок відсічення ботів/аномалій.

10) Безпека, доступ і комплаєнс

WAF/бот-менеджмент: сигнатури, поведінкові евристики, захист від сканерів бонусів.
Signed URLs/Headers для медіа та приватних завантажень.
mTLS к origin и IP allow-list.
GDPR/PII/PCI: не кешувати чутливі дані; API з персональними відповідями -'no-store'.
Geo-фільтри/блокування на краю за вимогами регуляторів ринку.

11) Мережа та протоколи

Увімкніть HTTP/2/3 на CDN, TLS resumption і OCSP stapling.
Brotli (br) для текстових форматів, gzip - fallback.
TCP/QUIC-тюнінг (у провайдера) → менше впливу втрат, особливо на мобільній мережі.

12) Спостережуваність і SLO для CDN

• Hit Ratio (overall і за префіксами), Origin Offload.
• TTFB P50/P95/P99 по регіонах/ASN.
• Throughput/Errors за кодами статусу (edge/origin).
• Purge latency (час доставки інвалідації).
• Image transform latency (якщо використовуєте ресайзинг на краю).

• Каталог ігор: TTFB P95 ≤ 150 мс, Offload ≥ 85%.
• Медіа (зображення): Hit Ratio ≥ 90%, помилки трансформацій <0. 1%.
• API GET «довідники»: TTFB P95 ≤ 200 мс, Revalidation Hit ≥ 60%.

13) FinOps: Вартість кешу

Offload = менше egress з origin → прямі $ -вигоди.
Tiered + shield ріжуть «шторми» і MISS-навантаження.
Оптимізація зображень (AVIF/WebP/resize) дає найбільшу економію трафіку.
Контролюйте P95 ваги відповіді і «дорогі MISS» (байти × кількість × регіон).

14) Конфіги і правила (фрагменти)

14. 1 Заголовки origin (Nginx)

nginx статика с версионированием location ~ \.(css    js    woff2)$ {
add_header Cache-Control "public, max-age=31536000, immutable";
}

полустатика каталога location /catalog/ {
add_header Cache-Control "public, max-age=300, stale-while-revalidate=600, stale-if-error=600";
add_header Vary "Accept, Accept-Language";
}

14. 2 Нормалізація ключа на edge (псевдо)

js addRule((req) => {
// очищаем шум req.cookies.clearExcept(['ab', 'locale']);
// ключ = method+path+критичные query key = `${req.method}:${req.path}?lang=${q.lang}&currency=${q.cur}`;
req.setCacheKey(key);
req.setVary(['Accept', 'Accept-Encoding', 'Accept-Language']);
});

14. 3 Signed URL (ідея)

/media/{path}?exp=1735707600&sig=HMAC_SHA256(secret, path    exp    ip)
На edge: проверка exp и подписи, опционально привязка к IP/ASN.

15) Процеси релізу та експлуатації

Release hooks: автоматичний purge за тегами/префіксами після деплоя.
Prewarm-список: топ-шляхи по трафіку/конверсії - прогріти заздалегідь.
Каталог TTL-матриця: узгоджена з продуктом/маркетингом.
Інциденти: при зростанні MISS/TTFB - включаємо stale-if-error, «знімаємо» дорогі трансформації на edge до стабілізації origin.

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

1. Карта контенту (статика/напівстатика/API) і TTL-матриця.
2. Коректні'Cache-Control','ETag/Last-Modified','Vary'.
3. Ключ кеша без «шуму», cookie-стриппінг, whitelists.
4. Tiered caching + origin shield по регіонах.
5. Purge за тегами/префіксами, soft purge, prewarm-процедури.
6. Edge-функції: нормалізація, geo-логіка, Signed URLs.
7. Оптимізація зображень (WebP/AVIF/resize), HLS-сегменти для відео.
8. WAF/бот-фільтри, geo-обмеження, mTLS до origin.
9. SLO-дашборди: TTFB, Hit Ratio, Offload, помилки трансформацій.
10. FinOps-звіти: $/GB, дорогі MISS, регіони-лідери по egress.

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

'no-cache'всюди «про всяк випадок».
Ключ кешу включає всі query/заголовки → нульовий Hit Ratio.
Cookie-залежні відповіді для статики (ламає кеш цілком).
Очищення всього CDN при кожному релізі.
Довгі синхронні трансформації на edge під час піків.
Відсутність'stale-while-revalidate '/' stale-if-error'- різкі деградації UX.
Кешування персональних даних/відповідей без'no-store'.

18) Контекст iGaming/фінтех: Практичні ноти

Турніри/івенти: короткі TTL на лідерборди (2-10 сек) + SWR; prewarm карток ігор і банерів.
Гео-ліцензування: edge-блокування/редиректи по країні, валюта/локаль в ключі кеша.
Промо і купони: кешуємо банери/умови, але не персональні ліміти.
Відповідальні ігри: сторінки політики/лімітів - напівстатика з SWR; персональні дані - тільки'no-store'.
PSP/KYC вебхуки: не через CDN, або edge-pass-through без кешу і з жорсткими таймаутами.

Підсумок

Сильна CDN-стратегія - це правильні заголовки і ключ кеша, tiered/shield для зниження MISS, edge-функції для нормалізації і захисту, інвалідація/прогрів для швидких релізів і спостережуваність з SLO і FinOps. Дотримуючись цих принципів, ви отримаєте швидкий і економічний периметр, який витримає піки і зробить TTFB передбачуваним для користувачів і партнерів.