Memorizzare nella cache e limitare il rate degli upstream

Un modello insistente può richiamare uno strumento più volte. Senza protezioni, può sovraccaricare il database o l'API sottostante. ⚠️

Una cache memorizza i risultati recenti, così una richiesta identica riceve subito la risposta invece di interrogare nuovamente il servizio upstream.

Costruisca la chiave della cache a partire dagli argomenti dello strumento, così la stessa città o lo stesso id riutilizza la risposta memorizzata, mentre ogni nuovo valore viene recuperato nuovamente.

Imposti un tempo di permanenza in cache, così i dati memorizzati scadono. Le risposte obsolete vengono aggiornate, mantenendo i risultati rapidi e ragionevolmente attuali.

Memorizzi in cache le letture idempotenti, mai le azioni con effetti collaterali. Non vorrebbe che una scrittura memorizzata in cache ignorasse silenziosamente una modifica reale.

Un limite di frequenza stabilisce con quale frequenza può essere eseguito uno strumento, impedendo a un modello fuori controllo di inviare migliaia di richieste in un breve intervallo.

Uno schema comune è il token bucket: ogni chiamata consuma un token, i token vengono ricaricati nel tempo e, quando il contenitore è vuoto, occorre attendere.

Adatti il limite alla quota dell'API. Restare al di sotto della sua quota evita le risposte 429 e impedisce che l'accesso venga limitato.

Se un servizio upstream risponde 429 Too Many Requests, faccia una pausa e riprovi più tardi applicando un backoff, invece di insistere con ancora più richieste.

Un semaforo limita il numero di chiamate che raggiungono contemporaneamente il backend, attenuando i picchi affinché il servizio upstream non venga mai sovraccaricato.

Quando applica una limitazione, comunichi chiaramente al modello che è soggetto a un limite di frequenza, così potrà attendere o provare un approccio diverso.

Ha protetto i servizi upstream con una cache, limiti di frequenza e backoff, mantenendo al sicuro i backend dalle chiamate incontrollate del modello. 🎯