Технологии и Инфраструктура → 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 предсказуемым для пользователей и партнеров.