Technologie et infrastructure → Niveaux de cache et stockage

Niveaux de cache et stockage des données

1) Pourquoi avez-vous besoin d'un cache multicouche

Kesh est un chemin de réponse court sans aller dans les sous-systèmes « chers » (OBD, API externes, réseaux). L'empilement distribue la charge : Navigateur → CDN/edge → couche d'application → cache distribué → base de données/stockage. Objectifs : réduire le P95/P99, décharger l'origin, résister plus fermement aux pics et réduire le coût de l'octet.

2) Carte des niveaux de cache

1. Браузер: `Cache-Control`, `ETag`, `Last-Modified`, `stale-while-revalidate`.
2. CDN/Edge: TTL/ключ, Vary, Signed URLs, image-resize; tiered/shield.
3. API Gateway/Service Mesh : Cache de réponse à courte vie sur le GET sécurisé.
4. Application (in-process) : LRU/LFU, near-cache pour clés « chaudes », millisecondes.
5. Cache distribué (Redis/Memcached) : couche principale pour la dynamique.
6. Caches OBD : Tampons Pg/Innodb, PgBouncer multiplexing, vues materialized.
7. Disk/Object Stors : snapshots precomputés, blob-cache (par exemple, S3 + CDN).

Le principe : "plus l'utilisateur est proche - plus la TTL est courte et moins la personnalisation ; plus les données sont proches, plus la politique de cohérence est riche".

3) Modèles de cache

Cache-Aside (Lazy) : Nous lisons → à la MISS, nous chargeons de la source → mettons dans le cache. Simple, donne le contrôle de TTL.
Read-Through : l'application lit à travers le cache, qui lui-même tire de la source. Il est commode de centraliser la politique.
Write-Through : l'enregistrement va directement au cache et à la source. C'est plus cohérent, mais plus cher à enregistrer.
Write-Back (Write-Behind) : nous écrivons dans cache, la source est mise à jour asynchrone (file d'attente). Vitesse élevée, des garanties de livraison et d'idempotence sont requises.
Refresh-Ahead : les clés « top » mettent à jour la valeur avant l'expiration de la TTL.

Où : cartes de jeux/catalogues - cache-aside/read-through ; compteurs/leaders - write-back + CRDT/agrégation ; les annuaires de devises/limites sont read-through avec TTL contrôlé.

4) Clés, segmentation et neuming

Шаблон: `domain:entity:{id}:v{schema}|region={R}|currency={C}|lang={L}`.
N'incluez dans la clé que ce qui change vraiment la réponse (région, monnaie, langue, version du schéma).
Versioner les schémas : en cas de changements incompatibles, augmentez 'vN' dans la clé en évitant les purges massives.
Namespacing par produit/tenant : 'tenant : {t} :...' - critique pour le multi-tenant.
Un filtre Bloom sur « l'existence d'une clé » peut réduire les campagnes vers la source.

5) TTL, fraîcheur et handicap

• statique (fichiers hachés) : 30-365 jours + 'immutable' ;
• catalogues/bannières : 5-60 minutes + « stale-while-revalidate » ;
• leaders/cotations : 2-15 secondes ;
• annuaires (devises/limites) : 1-10 minutes.
• Handicapé par des événements : nous publions le produit. mise à jour '→ invalidation de la clé de point/préfixe.
• Tag-based purge : nettoyage de groupe par tags (version promo/catalogue).
• Soft-Expiry : Après l'expiration de la TTL, nous donnons l'obsolète comme « stale », nous mettons à jour en parallèle (SWR/SIE).
• Keys convertis> purge de masse : moins cher et plus sûr.

6) Stampede, clés « chaudes » et concurrence

• Single-flight (request coalescing) : un leader met à jour la clé, les autres attendent.
• Jitter TTL : Brouiller les expirations en évitant l'effondrement d'une pièce.
• SWR localement : nous donnons la valeur périmée à l'utilisateur, en arrière-plan, nous la mettons à jour.

• réplication de la clé « chaude » en plusieurs slots 'key # 1.. N', distribuée en lecture ;
• near-cache dans la mémoire du processus ;
• prewarm/refresh-ahead avant les pics (tournois/matchs).
• Limites de mise à jour concarrensi pour les clés lourdes.

7) Consistance et couches croisées

Write-invalidate : Lors de l'écriture à la source - handicaper synchroniquement les clés correspondantes (pub/sub).
Read-repair : en cas de divergences, mettez à jour le cache avec une valeur correcte.
Eventual vs Strong : les transactions monétaires critiques sont lues directement/avec un court TTL ; UI-vitrines et statistiques - eventual.
CRDT/agrégateurs : pour les compteurs/notations distribués, structure « merge-safe » (G-Counter, Top-K sur les flux).
Handicap en cascade : la mise à jour du « jeu » invalide la carte + liste + cache de recommandations utilisateur.

8) Sérialisation, compression et format

Formats : Protobuf/MessagePack plus rapide que JSON ; pour CDN/navigateur - JSON avec Brotli.
Compression dans Redis : bénéfique pour les objets> 1-2 Ko, mais surveillez votre CPU.
Réponses partielles/champs à la demande : moins d'octets → moins de TTFB et RAM.

9) Politiques de déplacement et taille

LRU (par défaut) - sécurisé ; LFU - mieux pour le contenu « populaire ».
Taille des clés/valeurs : gardez le contrôle (métriques 'avg value size', 'max').
Quotas de namespace/tenant pour qu'un seul produit ne « mange » pas le cache entier.

10) Sécurité et PII/PCI

Données personnelles/financières - ne pas mettre de cache sur le CDN/edge et dans les couches communes ; utilisez des jetons/projections.
Cryptage des valeurs sensibles dans Redis via client-side crypto (avec prudence pour les pertes de contrôle TTL).
ACL rigoureux et isolation des réseaux ; NAT/IP fixe pour egress aux fournisseurs.

11) Observabilité et Casha SLO

• Hit Ratio (par calques et préfixes), Original Offload.
• TTFB/P95/P99 avant/après la cache, Latinity Redis.
• Evictions, OOM, keyspace hits/misses.
• Stampede rate (proportion de mises à jour parallèles), refresh time.
• Stale served % и Freshness lag.

• Catalogue des jeux : Hit Ratio ≥ 85 %, TTFB P95 ≤ 150 ms (edge).
• Guides API : Revalidation-hit ≥ 60 %, P95 ≤ 200 ms.
• Redis : Opération P99 ≤ 5 ms, evictions pas plus de 1 % par heure.

12) FinOps : le coût de la cache

$/GB-mois RAM vs $/RPS origin : comptez le point de récupération.
Offload et egress : CDN + Redis réduisent le trafic sortant de la région-origine.
Image/WebP/AVIF et dénormalisation donnent la plus grande économie d'octets.
Limitez « chers MISS » : l'analyse « octets × MISS × la région ».

13) Exemples (fragments)

13. 1 Cache-Aside avec vol unique (pseudo-code)

python def get(key, ttl, loader):
val = redis. get(key)
if val: return val with single_flight (key): # only one updates val = redis. get (key) # double check if val: return val data = loader () # request to source redis. setex(key, ttl_with_jitter(ttl), serialize(data))
return data

13. 2 Publication du handicap par événement

json
{
"event": "game. updated",
"game_id": "g123",
"affected": ["catalog:list:region=TR", "game:card:g123:"]
}

Le consumer est signé sur le canal et fait de 'DEL '/' PUBLISH' les clés/étiquettes correspondantes.

13. 3 Clé avec la version du schéma et le local

game:card:v2:id=g123    region=BR    currency=BRL    lang=pt-BR

14) Chèque de mise en œuvre

1. Carte des niveaux de cache et matrice TTL (statique/semi-statique/API).
2. Neuming des clés : domaine, version du schéma, local/région/monnaie, tenant.
3. Sélection du modèle per-endpoint (aside/read-through/write-through/back).
4. SWR/SIE, single-flight et TTL-gitter contre stampede.
5. Handicapé par des événements (pub/sub), tag-purge pour les groupes.
6. Près-cache pour les clés « chaudes » et prewarm avant les pics.
7. Formats et compressions (protobuf/MsgPack, Brotli), contrôle de taille.
8. Politiques LRU/LFU, quotas namespace/tenant.
9. SLO/метрики: hit ratio, latency, evictions, stale %, freshness lag.
10. Sécurité : no-store pour personnel, tokenization, réseau/ACL.

15) Anti-modèles

« no-cache » « au cas où » et les refus de TTL sont nuls.
La clé comprend tous les titres query → l'explosion de la cardinalité.
Purge de masse « total CDN/Redis » à chaque sortie.
L'absence de protection contre le stampede et l'expiration unique des « clés supérieures ».
Un redis commun unique sans quotas/isolement ; le tenant « chaud » mange tout le cache.
Cache les réponses personnelles à edge/CDN.
Pas de télémétrie freshness/evictions → contrôle aveugle.

16) Contexte iGaming/fintech : notes pratiques

Liderboards/classements : TTL 2-10 s, flux aggregate + CRDT, SWR en cas de défaillance.
Catalogue de jeux/bannières : CDN + Redis ; clé : région/monnaie/langue ; invalidité par les étiquettes « promo : update ».
Statuts de paiement : pas de cache sur le chemin d'écriture ; la lecture est un court TTL (≤3 -5 s) ou une requête directe.
Réponses KYC/AML : Créez des dérivés non PII (statuts), ne stockez pas d'images/documents dans Redis.
Chemin VIP : namespace séparé/pool Redis, service prioritaire.

Résultat

Une stratégie de cache forte est l'architecture des niveaux, les bons modèles de mise à jour, le TTL/handicap réfléchi, la résistance au stampede, les clés et versions soignées, ainsi que l'observation et les FinOps. En suivant ces principes, vous stabiliserez les résidus de P95/P99, réduirez la charge de travail sur les sources et obtiendrez un coût prévisible de milliseconde - exactement là où c'est le plus important pour le produit et l'entreprise.