--- title: "Caching di API ad alto traffico con Redis ed Elasticsearch" description: "Misurate prima il P95, poi usate cache-aside, TTL sensati, invalidazione e difese dalle stampede con Redis ed Elasticsearch. E cosa non mettere mai in cache." canonical: https://sdk.enterprises/it/insights/caching-high-traffic-apis language: it --- # Caching di API ad alto traffico con Redis ed Elasticsearch Aggiornato il: 2026-09-25 > Per mettere in cache un'API ad alto traffico, misurate prima di tutto, poi mettete uno strato cache-aside in Redis davanti agli endpoint più lenti e più letti, con TTL espliciti, invalidazione a ogni scrittura e protezione contro le cache stampede, cioè le ondate di richieste simultanee su una chiave scaduta. Usate Elasticsearch per la ricerca e gli elenchi filtrati che il database principale gestisce male, e non mettete mai in cache dati specifici di un utente o che devono essere strettamente coerenti senza una progettazione mirata. ## Misurate la latenza P95 prima di aggiungere qualsiasi cache Le medie nascondono proprio le richieste di cui si lamentano gli utenti. Monitorate la latenza P95 e P99 per endpoint, insieme al volume di richieste, per vedere quali route sono al tempo stesso lente e molto usate. Poi scoprite dove se ne va il tempo. Una trace o una semplice scomposizione dei tempi per richiesta di solito mostra se il costo viene da una query lenta, da query ripetute, da una chiamata a un'API esterna o dalla serializzazione. Mettere in cache una risposta il cui vero problema è un indice mancante nasconde quel problema solo fino al prossimo cache miss. - Registrate P50, P95 e P99 per endpoint, non un unico dato globale - Ordinate gli endpoint per volume di richieste moltiplicato per latenza, per vedere dove la cache rende di più - Controllate il rapporto tra letture e scritture: i dati letti molto più spesso di quanto cambino sono i candidati migliori - Correggete indici mancanti e query N+1 prima di aggirarli con una cache ## Usate cache-aside come pattern predefinito Con il cache-aside l'applicazione interroga prima Redis. In caso di hit restituisce il valore in cache. In caso di miss legge dal database, scrive il risultato in Redis con un TTL e lo restituisce. Il pattern mantiene il database come fonte di verità e, se qualcosa si guasta, degrada in modo sicuro. Se Redis è lento o non disponibile, l'applicazione ripiega sul database, con un timeout breve e un circuit breaker, così una cache in difficoltà non rallenta tutte le richieste. Progettate le chiavi con cura. Includete il tipo di risorsa, l'identificativo, la versione dell'API e ogni parametro che cambia la risposta, come la lingua o la pagina. Uno schema di chiavi prevedibile è ciò che rende possibile, in seguito, un'invalidazione mirata. ## Fissate i TTL in base a quanto possono invecchiare i dati, poi invalidate a ogni modifica Un TTL è una decisione di business scritta sotto forma di numero. Chiedetevi quanto può essere vecchio un dato prima di danneggiare un utente o un sistema a valle, e fissate il TTL a partire da questa risposta. Il punteggio di una partita in diretta e un articolo d'archivio tollerano livelli di obsolescenza molto diversi. Affidarsi solo alla scadenza significa servire dati obsoleti finché il TTL non si esaurisce. Per i dati che la vostra applicazione modifica, cancellate o sovrascrivete la chiave dopo il commit della scrittura, idealmente a partire da un evento emesso dopo la transazione, così la cache non contiene mai dati che il database ha annullato con un rollback. Aggiungete ai TTL una piccola variazione casuale (jitter), così le chiavi scritte nello stesso momento non scadono tutte nello stesso istante. - TTL breve, di pochi secondi, per i dati che cambiano in fretta e per cui una leggera obsolescenza è accettabile - TTL più lungo con invalidazione a ogni scrittura per i dati che controllate voi e che cambiano di rado - Chiavi con versione, dove incrementare un numero di versione invalida in un colpo solo un intero gruppo di chiavi ## Proteggete il database dalle cache stampede Una stampede si verifica quando una chiave molto richiesta scade e molte richieste concorrenti la mancano nello stesso momento, inviando tutte la stessa query costosa al database. Su un'API ad alto traffico questo può sovraccaricare il database proprio nel momento del picco. Combinate almeno due di queste difese sulle chiavi più richieste. - Accorpamento delle richieste: una sola richiesta ricostruisce la chiave sotto un breve lock Redis impostato con NX e una scadenza, mentre le altre attendono un attimo o servono il valore precedente - Stale-while-revalidate: salvate una scadenza morbida dentro il valore, continuate a servire la copia obsoleta oltre quella scadenza e aggiornate in background - Aggiornamento anticipato probabilistico: ricostruite di tanto in tanto una chiave molto richiesta prima che scada, con una probabilità che cresce man mano che la scadenza si avvicina - Preriscaldamento: popolate le chiavi molto richieste già note prima di un picco di traffico programmato, come un grande evento in diretta ## Usate Elasticsearch per ricerca ed elenchi, non come cache generica Redis dà il meglio negli accessi chiave-valore: un singolo oggetto, un frammento calcolato, un contatore di rate limiting. Elasticsearch svolge un altro lavoro: ricerca full-text, filtri a faccette ed elenchi ordinati che in un database relazionale costano molto da calcolare. Trattate l'indice Elasticsearch come un modello di lettura alimentato dal database principale, tramite eventi di modifica o una sincronizzazione programmata, e accettate che sia coerente solo a regime (eventual consistency). Lasciate al database l'ultima parola sulle scritture e su tutto ciò che deve essere esatto. Sulla piattaforma di media sportivi di NorthStar Network, che serve 50M+ utenti al mese, i nostri ingegneri hanno riprogettato l'architettura di API critiche e ripensato il caching tra Redis ed Elasticsearch, riducendo i tempi di risposta P95. ## Sappiate che cosa non mettere in cache Il bug di caching più costoso è servire i dati di un utente a un altro. Verificate che ogni endpoint in cache includa l'identità nella chiave, e testatelo con due account diversi prima del rilascio. - Le risposte che dipendono dall'identità o dai permessi di chi chiama, a meno che la chiave non includa l'utente o il ruolo - I dati che devono essere strettamente coerenti, come saldi, disponibilità di magazzino al momento del pagamento o tutto ciò che serve a decisioni di autorizzazione - Gli endpoint di scrittura, i token monouso e tutto ciò che ha effetti collaterali - Gli endpoint con poco traffico, dove una cache aggiunge complessità e un nuovo modo di guastarsi in cambio di un guadagno minimo - I payload molto grandi, che espellono tante chiavi più piccole e più richieste ## Rendete la cache osservabile, altrimenti non potete fidarvi Monitorate l'hit ratio per prefisso di chiave, l'uso di memoria e le espulsioni di Redis, la latenza dei comandi Redis e il carico del database, accanto al P95 dell'API, sulla stessa dashboard. Quando il P95 si muove, dovete poter dire in pochi minuti se la causa è la cache, il database o un servizio a monte. Impostate un allarme su un calo improvviso dell'hit ratio, che spesso indica che un deploy ha cambiato il formato di una chiave, e sull'aumento delle espulsioni, che indica che la cache è troppo piccola per il suo insieme di dati attivo. Ci occupiamo delle prestazioni delle API come di un blocco di lavoro definito: misurazione, riprogettazione dello strato di cache e consegna di dashboard e runbook al team che lo gestisce. ## Punti chiave - Misurate il P95 per endpoint e correggete i problemi delle query prima di aggiungere una cache. - Il cache-aside in Redis è la scelta predefinita più sicura, perché il database resta la fonte di verità. - Fissate i TTL in base a quanto possono invecchiare i dati, e invalidate a ogni scrittura per i dati che controllate. - Proteggete le chiavi più richieste dalle stampede con lock, stale-while-revalidate o preriscaldamento. - Usate Elasticsearch come modello di lettura coerente a regime per ricerca ed elenchi, non come cache generica. ## Domande frequenti ### Meglio Redis o Elasticsearch per mettere in cache le risposte di un'API? Usate Redis per il caching chiave-valore di oggetti, frammenti calcolati e contatori, perché gli accessi per chiave sono veloci e semplici da invalidare. Usate Elasticsearch quando la parte costosa è la ricerca, il filtro o l'ordinamento su molti record, e trattate il suo indice come un modello di lettura più che come una cache. ### Qual è un buon TTL per le risposte di un'API? Non esiste un valore universale. Fissate ogni TTL in base a quanto può essere vecchio quel dato senza danneggiare un utente, usate pochi secondi per i dati che cambiano in fretta e abbinate i TTL più lunghi a un'invalidazione a ogni scrittura. Aggiungete un jitter casuale perché chiavi collegate non scadano insieme. ### Come evitare una cache stampede in Redis? Lasciate che una sola richiesta ricostruisca una chiave scaduta prendendo un breve lock con SET e l'opzione NX, e fate attendere un attimo le altre richieste oppure servite loro il valore precedente. Lo stale-while-revalidate e l'aggiornamento anticipato delle chiavi più richieste riducono a monte il numero di scadenze brusche. ## Servizi correlati - [Software su misura](https://sdk.enterprises/it/services/product-engineering)