Ridurre latenza e carico sul database è uno degli obiettivi ricorrenti nello sviluppo di applicazioni Azure. Il caching interviene su due fronti distinti: dati applicativi (cache in-memory come Azure Cache for Redis) e contenuti statici serviti vicino all’utente (CDN / Azure Front Door). Sceglierli e configurarli correttamente, con una strategia di espirazione coerente, è il cuore di questa unità.

Pattern di caching applicativo

Diversi pattern rispondono a esigenze diverse:

  • Cache-aside (lazy loading): l’applicazione controlla prima la cache; in caso di miss legge dalla sorgente, popola la cache e restituisce il dato. È il pattern più comune con Redis: la cache non conosce il database e resta popolata solo con ciò che viene realmente richiesto.
  • Data cache: si materializza in cache un intero dataset o oggetti di dominio (spesso serializzati in JSON) per abbattere query costose e ripetitive.
  • Session cache: stato di sessione condiviso fra più istanze di App Service o Container Apps, indispensabile quando il bilanciatore non garantisce sticky session. Redis è il backing store tipico del session state distribuito.
  • Output / response cache: si conserva l’HTML o la risposta già renderizzata; in ASP.NET Core la Output Caching middleware può usare Redis come store condiviso fra istanze.

Un principio chiave da esame: la cache è effimera. Non deve mai essere l’unica copia di un dato che non puoi permetterti di perdere.

Tier di Azure Cache for Redis

La scelta del tier è una decisione architetturale, non solo di prezzo:

  • Basic: nodo singolo, nessuno SLA. Solo per dev/test.
  • Standard: replica primario/replica su due nodi con failover automatico e SLA. È il minimo per la produzione.
  • Premium: aggiunge clustering (sharding per scalare oltre la memoria di un nodo e aumentare il throughput), persistence (RDB snapshot o AOF per sopravvivere a un riavvio), integrazione VNet / private endpoint, geo-replica e zone di disponibilità.

Da ricordare: se lo scenario richiede persistenza dei dati, isolamento in rete privata o dimensioni molto grandi, la risposta è Premium; se serve solo alta disponibilità, Standard è sufficiente. I tier Enterprise (basati su Redis Enterprise) aggiungono moduli come RediSearch e la geo-replica attiva-attiva, utili in scenari avanzati.

Espirazione e invalidazione

La coerenza fra cache e sorgente si governa con la TTL (time-to-live):

SET product:42 "{...}" EX 300
  • Assegna sempre una TTL: senza scadenza la cache può servire dati stale indefinitamente e riempirsi fino all’eviction (policy tipica allkeys-lru).
  • Per dati che cambiano, combina TTL corta con invalidazione esplicita: alla scrittura sul database, aggiorna o cancella (DEL) la chiave interessata.
  • Bilancia i due estremi: TTL troppo lunga → dati obsoleti; TTL troppo corta → cache stampede e hit ratio basso.

CDN e Azure Front Door per i contenuti statici

Per immagini, CSS, JavaScript, video e asset di uno Storage Account o di un’app web, la cache va spostata all’edge, geograficamente vicino all’utente. Azure Front Door è oggi la scelta strategica di Microsoft: unisce caching edge, routing globale via Anycast, WAF e terminazione TLS. Punti operativi:

  • Il comportamento di cache si controlla con l’header Cache-Control dell’origine e con le regole del Rules Engine (override della cache duration, query string caching, compressione).
  • Serve contenuti statici e pubblici; per contenuti dinamici o personalizzati per utente la cache edge va disabilitata o filtrata con attenzione.
  • La purge invalida manualmente gli asset dopo un deploy, evitando di attendere la scadenza naturale.

Redis e Front Door sono complementari: il primo cachea dati applicativi lato server, il secondo cachea risposte statiche lato edge.

Trappole tipiche d’esame

  • Scenario: dati altamente volatili (prezzi in tempo reale) messi in cache senza strategia → gli utenti vedono valori errati. Risposta giusta: TTL breve più invalidazione esplicita alla scrittura, oppure non cacheare affatto.
  • Scenario: serve persistenza dei dati Redis a un riavvio o isolamento in VNet. Risposta giusta: tier Premium (Standard/Basic non offrono persistence né private endpoint).
  • Scenario: session state condiviso fra più istanze di App Service dietro load balancer. Risposta giusta: Redis come distributed session cache, non memoria in-process.
  • Scenario: dopo il deploy gli utenti vedono ancora il vecchio JS servito dalla CDN. Risposta giusta: eseguire una purge dell’endpoint (o versionare i file), non solo aspettare la TTL.
  • Scenario: cacheare all’edge pagine con dati personalizzati per utente. Risposta giusta: disabilitare la cache edge o variarla correttamente; la CDN/Front Door serve contenuti statici e pubblici.