Considerazioni di natura progettuale

Gestione degli errori: se la cache non è disponibile per qualsiasi motivo, l'applicazione dovrebbe procedere come se tutti gli elementi fossero mancanti nella cache. L'esistenza del livello di cache non dovrebbe aggiungere fragilità a un'applicazione.

TTL: È possibile configurare un singolo valore TTL per tutte le voci della cache o utilizzare valori TTL diversi a seconda della voce (ad esempio, get_itemquery, o cache). scan È anche possibile avere un valore TTL diverso per le voci negative della cache (richieste che non hanno restituito articoli).

Capacità consumata: quando restituisci una risposta memorizzata nella cache, ti consigliamo di modificare le ConsumedCapacity metriche della risposta per indicare un consumo di lettura pari a zero.

Rimozione dei metadati di risposta: dovresti anche rimuovere la ResponseMetadata sezione nella risposta. In questo modo si evita il rischio che qualcuno veda un RequestId messaggio e pensi che sia attuale mentre in realtà proveniva da ore prima.

Aggiunta di metadati della cache: è utile aggiungere una CacheMetadata sezione alla risposta. Questa sezione può riportare l'ora in cui il valore è stato memorizzato (utile per misurare lo stallo) e la libreria client e la versione in cui è stato memorizzato il valore (che potrebbe essere utile quando si esegue un aggiornamento senza interruzioni da una versione all'altra in cui il formato cambia).

Determinazione dello schema della tabella: per determinare la chiave primaria da un'operazione di scrittura per l'invalidazione della cache, è necessario conoscere lo schema della tabella. È possibile ottenere queste informazioni utilizzando una describe_table chiamata e una cache a lungo termine ElastiCache al primo utilizzo (solo una volta) per ogni tabella.

Accettare i client anziché crearli: un vantaggio dell'accettare le istanze dei client DynamoDB e Redis nel costruttore (anziché crearle all'interno dello shim in base a parametri passati) è che consente al chiamante del costruttore di determinare i dettagli, ad esempio se debba essere impostato. read_from_replicas=True

Funzionalità dello spazio dei nomi: può essere conveniente supportare uno spazio dei nomi opzionale nel costruttore che isola tutte le letture e le scritture della cache in quel namespace. L'uso di uno spazio dei nomi è ideale per i test, perché ogni esecuzione con uno spazio dei nomi diverso sembra iniziare con una cache vuota e non ha effetti collaterali rispetto alle esecuzioni precedenti. È inoltre possibile simulare lo svuotamento dell'intera cache in produzione semplicemente modificando lo spazio dei nomi. Questo può essere implementato aggiungendo automaticamente un prefisso a ciascuna chiave di ricerca.

Scan caching: è difficile sapere se le scan chiamate devono essere memorizzate nella cache. Quando si esegue una scansione completa della tabella una tantum, non è consigliabile riempire la cache con pagine di dati scansionati di grandi dimensioni che non verranno lette una seconda volta. D'altra parte, molti carichi di lavoro eseguono scansioni ripetute, soprattutto di tabelle più piccole, per fornire i dati completi più recenti della tabella a più consumatori a valle. Un compromesso potrebbe consistere nell'implementare un sistema in cui siano necessarie due chiamate e ogni chiamata abbia la stessa firma (entro il periodo di tempo TTL), affinché la risposta di scansione risultante venga memorizzata nella cache. In questo modo si evita di riempire la cache durante una sola scansione completa della tabella e si consentono cicli di scansione stretti per sfruttare i vantaggi della memorizzazione nella cache. La prima scansione inserisce un piccolo segnaposto nella cache per contrassegnare la richiesta come effettuata una sola volta. La seconda scansione sostituisce il valore del token con il payload effettivo, che può arrivare fino a 1 MB.