CDN-cache et TTL-optimisation

Cache-Control: public, max-age=31536000, immutable

Cache-Control: public, s-maxage=300, max-age=60, stale-while-revalidate=600, stale-if-error=86400
ETag: "a1c3..."

Clé cache : conception et normalisation

L'objectif est que les mêmes demandes tombent dans le même objet.

Normaliser l'URL : registre, double slashs, trailing-slash, ordre des paramètres query.
Ignorer « bruit » : 'utm _', 'fbclid', 'gclid', balises ref arbitraires.
Vary limité : uniquement des titres vraiment significatifs ('Accept-Encoding', parfois 'Accept', 'Accept-Language' pour local).
Classe device : si nécessaire, utilisez 2-3 classes (mobile/desktop/tablet) plutôt que des branches utilisateur-agent infinies.
Contexte auth : par défaut, ne manquez pas le contexte privé ; utilisez les URL signées/cookies-bypass ou séparez les chemins publics/privés.

Surrogate-Key: product:123 catalog
Cache-Control: public, s-maxage=300, stale-while-revalidate=600
Vary: Accept-Encoding

Stratégie TTL par type de contenu

Politiques relatives aux personnes handicapées

Par URL/Prefix : « tout balayer sous '/static/2025-11-05/' ».
By Tag/Key : « Retirez tout 'catalogue' et 'product : 123' ».
Soft purge : marquer comme obsolète, ne pas effacer l'objet - remplissage plus rapide.
Event-driven : CI/CD ou admin-event appelle webhook « invalidate tags ».

Recommandation : combiner les deux tactiques : le versioning des chemins pour les assets + tag-purge pour le contenu/pages.

Tiered-cache, origin-shield и prewarm

Tiered-cache : les couches régionales du CDN → moins de demandes d'origin.
Origin-shield : un POP « bouclier » à origin - améliore la localisation et le hit-ratio.
Prewarm (pré-fetch) : échauffer les URL/caches chauds avant l'événement/sortie.
Negative-cache : Badigeonnez brièvement le 5xx/Timeout (30-120 s) pour ne pas écraser l'origin par la tempête de rétrogrades.

API Cache : Quand vous pouvez

Seulement GET/HEAD et idempotent.
Clé : chemin + query essentiel (par exemple, '? category =... & page =...').
Validation : 'ETag '/' Last-Modified' et le court 's-maxage'.
Filtres par utilisateur : apportez la personnalisation à la fonction client/edge ou utilisez signed-requests + réponse « publique ».

Cache-Control: public, s-maxage=30, max-age=5, stale-while-revalidate=120, stale-if-error=600
ETag: "feed-v42"

Protection contre l'empoisonnement au cache (cache poisoning)

Normalisation rigide des URL/en-têtes ; Liste blanche des paramètres dans la clé.
Découpe des en-têtes/doublons suspects ('X-Forwarded-', étendu 'Accept').
Restriction 'Vary' et contrôle de la taille/cola-va des titres.
Division des domaines : privé/admin - sur un nom distinct sans cache.
Validation des réponses : ne mettez pas en cache 4xx (sauf 404 pour les statiques), ne mettez pas en cache les pages « personnalisées » sans stratégie explicite.

Compression et formats

Brotli pour les textes (js/css/json), gzip - fallback ; Les assets comprimés sont admissibles.
Images : webp/avif où le support ; Utiliser 'Vary : Accept' + dérivés dérivés.
Range-requests pour vidéo/audio : CDN met en cache les cuves.
Contenu-Negotiation : Gardez le cardinal bas de la clé (device-class au lieu des UA bruts).

Observabilité et SLO

Mesures clés

Hit-ratio (by bytes/requests) на edge/tier/shield.
p50/95/99 TTFB par région et par type (statique/API).
Fill-rate/Origin egress - combien passe à origin.
304 taux et taille moyenne de la réponse.
Error budget : part de 'stale-if-error '/' SWR' de l'émission ; fréquence de purge.

Exemples de SLO

'p95 TTFB' de la statique régionale ≤ 120-150 ms, API GET des casiers ≤ 200-250 ms.
Edge hit-ratio statique ≥ 90 %, semi-dynamique ≥ 60 %.
Taux de réponse de la branche stale pour les erreurs ≤ 0. 5 % en 30 jours.

Config-Spargalki

Nginx (reverse-proxy devant le CDN ou en self-PoP)

nginx proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=CDN:512m max_size=100g inactive=7d;

map $args $clean_args {
"~(^    &)(utm_    gclid    fbclid) """; # default $ args simplified example;
}

server {
listen 443 ssl http2;
set $cache_key "$scheme$request_method$host$uri?$clean_args    $http_accept    $http_accept_encoding";
location /static/ {
proxy_cache CDN;
proxy_cache_key $cache_key;
proxy_ignore_headers Set-Cookie;
add_header Cache-Control "public, s-maxage=86400, max-age=3600, stale-while-revalidate=600" always;
proxy_pass https://origin_static;
}

location /api/public/ {
proxy_cache CDN;
proxy_cache_key $cache_key;
proxy_cache_valid 200 30s;
add_header Cache-Control "public, s-maxage=30, max-age=5, stale-while-revalidate=120, stale-if-error=600" always;
proxy_set_header If-None-Match $upstream_http_etag;
proxy_pass https://origin_api;
}
}

Envoy (SWR + negative-cache, concept)

yaml http_filters:
- name: envoy. filters. http. cache typed_config:
"@type": type. googleapis. com/envoy. extensions. filters. http. cache. v3. CacheConfig typed_config:
"@type": type. googleapis. com/envoy. extensions. cache. simple_http_cache. v3. SimpleHttpCacheConfig
Cache-Control/Surrogate-Control Header Cache Policies
We cache 5xx errors briefly via route/retry policy + local_rate_limit

Heders pour les assets « rapides »

Cache-Control: public, max-age=31536000, immutable
ETag: "hash"
Content-Encoding: br

Headers pour semi-haut-parleur (catalogues)

Cache-Control: public, s-maxage=600, max-age=120, stale-while-revalidate=1800, stale-if-error=86400
Vary: Accept-Encoding, Accept

FinOps : comment le cache économise de l'argent

Egress origin ↓, moins de CPU/DB → moins de dépenses d'infrastructure.
Moins de demandes avant les backends payants (search/index/images).
Métrique cible : $/réduction de p95 et $/réduction d'egress de 1 Go - suivre l'effet après le lancement.

Spécificité pour iGaming/fintech

Catalogues fournisseurs/assets : Chemins versionnés + TTL d'un an.
Événements/tournois : 1-5 min 's-maxage' + 'SWR' pour 10-30 min ; tag-purge lors de la mise à jour.
(Coefficients/tableaux) : Cache partiel des blocs JSON, TTL courts (5-30 s), pour les blocs personnels - rendu client.
PSP/endpoints de paiement : pas de cache, strict « no-store » ; ne mettre en cache que les manuels (tables BIN, statuts).
Antibot : mise en cache statique/GET, itinéraires « gris » pour les ASN suspects ; ne tolérez pas « Vary » par les gros titres bruyants.

Chèque d'implémentation

• La clé de cache est décrite : Normalisation de l'URL, liste de la query autorisée, 'Vary' seulement par le bon.
• Les voies publiques/privées sont séparées ; privé - « no-store » et bypass CDN.
• Introduction d'escaliers TTL pour les types de contenu ; « SWR/if-error » est configuré.
• Configuré tiered-cache + origin-shield ; inclus negative-cache 5xx (court).
• Il y a tag/URL purge, soft purge ; intégration avec CI/CD.
• La compression (br/gzip), les formats d'image Web et les réponses range sont inclus.
• Métriques : hit-ratio by layer, p95 TTFB, 304 rate, origin egress ; alertes aux échecs.
• Pleybooks : échauffement du cache avant les pics, purge d'urgence, dégradation de l'origin.

Erreurs typiques

Sans versio assets avec un grand TTL → des gangs « gonflés » chez les utilisateurs.
L'excès de « Vary » (selon « User-Agent », tous les titres) → une explosion de cardinalité et un faible hit-ratio.
Mise en cache 4xx/401/403/contenu privé.
L'absence de negative-cache → une avalanche de demandes d'origin dégradé.
Il n'y a pas de tag-purge → de points massifs et de « tempête » re-fill.
La clé cache inclut les paramètres UTM/ref « bruyants ».
TTL trop court pour la statique → charge excessive sur le CDN et l'origin.

Mini-playbooks

1) Réchauffer le cache avant l'événement

1. Collecte du top N URL par logs → 2) Prefetch parallèle (rate-limited) par région → 3) Check hit-ratio ↑ et p95 ↓.

2) Les cathologues d'urgence soft-purge

1. Envoyer 'PURGE '/tag-clear → 2) CDN donne stale et fond tire frais → 3) Vérifier l'absence d'épines sur origin.

3) Refus d'origin

1. 'stale-if-error' indique X heures → 2) Activer la bannière « travaux techniques » sur edge → 3) Par restauration - warm-up cible.

Total

Stratégie CDN forte = clé cache correcte + TTL sensée avec SWR/if-error + handicap géré + tiered/shield + observabilité. Fixez la politique dans les headers et IaC, mesurez hit-ratio et p95, prévoyez de vous réchauffer sous les pics - et les utilisateurs recevront toujours une réponse rapide, et l'origin restera en vie même à l'heure la plus chaude.