Pertimbangan desain

Poin desain lain yang perlu dipertimbangkan:

• Penanganan kesalahan: Jika cache menjadi tidak tersedia karena alasan apa pun, aplikasi harus melanjutkan seolah-olah semua item hilang cache. Keberadaan lapisan cache seharusnya tidak menambah kerapuhan pada aplikasi.

• TTL: Dimungkinkan untuk mengkonfigurasi nilai TTL tunggal untuk semua entri cache atau menggunakan nilai TTL yang berbeda tergantung pada entri (misalnya,, get_itemquery, atau cache). scan Dimungkinkan juga untuk memiliki nilai TTL yang berbeda untuk entri cache negatif (permintaan yang tidak mengembalikan item).

• Kapasitas yang dikonsumsi: Saat Anda mengembalikan respons yang di-cache, sebaiknya Anda menyesuaikan ConsumedCapacity metrik dalam respons untuk menunjukkan nol konsumsi baca.

• Penghapusan metadata respons: Anda juga harus menghapus ResponseMetadata bagian dalam respons. Ini menghindari risiko bahwa seseorang akan melihat RequestId dan berpikir bahwa itu saat ini ketika itu sebenarnya dari jam sebelumnya.

• Penambahan metadata cache: Sangat membantu untuk menambahkan CacheMetadata bagian ke respons. Bagian ini dapat melaporkan waktu penyimpanan nilai (berguna untuk mengukur kebuntuan) dan pustaka klien serta versi yang menyimpan nilai (yang mungkin berguna saat melakukan pemutakhiran tanpa batas dari satu versi ke versi lain di mana format berubah).

• Menentukan skema tabel: Untuk menentukan kunci utama dari operasi tulis untuk pembatalan cache, Anda harus mengetahui skema tabel. Anda bisa mendapatkan informasi ini dengan menggunakan describe_table panggilan dan cache jangka panjang ElastiCache pada penggunaan pertama (hanya sekali) untuk setiap tabel.

• Menerima alih-alih membangun klien: Keuntungan untuk menerima instance klien DynamoDB dan Redis di konstruktor (alih-alih membangunnya di dalam shim berdasarkan parameter yang diteruskan) adalah memungkinkan pemanggil konstruktor menentukan detail, seperti apakah harus disetel. read_from_replicas=True

• Fitur namespace: Akan lebih mudah untuk mendukung namespace opsional di konstruktor yang mengisolasi semua pembacaan dan penulisan cache Anda ke namespace itu. Menggunakan namespace sangat ideal untuk pengujian, karena setiap run dengan namespace yang berbeda tampaknya dimulai dengan cache kosong dan tidak memiliki efek samping dari proses sebelumnya. Anda juga dapat mensimulasikan pengosongan cache penuh dalam produksi hanya dengan mengubah namespace. Ini dapat diimplementasikan dengan secara otomatis menambahkan awalan ke setiap kunci pencarian.

• Scan caching: Sulit untuk mengetahui apakah scan panggilan harus di-cache. Saat melakukan pemindaian tabel penuh satu kali, Anda tidak ingin mengisi cache dengan halaman besar data yang dipindai yang tidak akan dibaca untuk kedua kalinya. Di sisi lain, banyak beban kerja melakukan pemindaian berulang, terutama terhadap tabel yang lebih kecil, untuk memberikan data tabel lengkap terbaru ke beberapa konsumen hilir. Satu kompromi adalah mengimplementasikan sistem di mana dibutuhkan dua panggilan, dan setiap panggilan memiliki tanda tangan yang sama (dalam periode waktu TTL), agar respons pemindaian yang dihasilkan akan di-cache. Ini menghindari pengisian cache selama pemindaian tabel penuh satu kali sambil mengaktifkan loop pemindaian ketat untuk mendapatkan manfaat dari caching. Pemindaian pertama menempatkan placeholder kecil di cache untuk menandai permintaan sebagai telah dibuat sekali. Pemindaian kedua menggantikan nilai token dengan muatan aktual, yang bisa sebesar 1 MB.