Cara Meta Menjaga Konsistensi Cache Saat Menggunakan Invalidation Cache (Terjemahan)

Cache Inconsistency

• server cache mengirim permintaan untuk x ke DB, dan sebelum respons DB x=42 tiba di cache
  • dari luar, x diperbarui menjadi x=43, dan x=43 dikirim ke cache melalui invalidation
  • cache menerima x=43 dan menerapkannya
  • respons x=42 tiba terlambat lalu diterapkan
• masalah di atas dapat diselesaikan dengan menambahkan versi pada data
• tetapi meskipun versi ditambahkan, jika eviction terjadi pada x=43, x=42 bisa diterapkan

Polaris: layanan pengukuran Cache Inconsistency

• proses kerja
  • Polaris juga menerima event invalidation
  • saat menerima event, Polaris mengecek semua server cache untuk melihat apakah masih menyimpan versi lama
  • jika cache memiliki versi lama, ini dianggap sebagai inconsistency dan dimasukkan kembali ke antrean agar bisa dicoba ulang
    • karena event invalidation bisa tiba terlambat di server cache
  • setelah waktu tertentu berlalu (1 menit, 3 menit, 5 menit, dan seterusnya), alarm inconsistency dikirim
• metrik
  • menampilkan metrik apakah penulisan cache yang setara dengan N nines selama M menit terakhir konsisten
  • jika 10 nines selama 5 menit, berarti dapat diketahui bahwa 1 dari 10 miliar penulisan cache dalam 5 menit terakhir mengalami inconsistency

Library logging untuk debugging Cache Inconsistency

• tidak mungkin mencatat semua penulisan cache
  • karena pada dasarnya cache memiliki workload yang berat di pembacaan, tetapi karena "logging" justru menjadi workload yang berat di penulisan
• karena itu dibuat library agar logging bisa dilakukan untuk time window tepat setelah invalidation terjadi
• library ditanamkan ke semua layanan yang terlibat dalam invalidation
• melalui logging, ketika inconsistency terjadi, proses hingga terjadinya bisa ditelusuri dalam bentuk timeline