Menangani Cache Invalidation dan Lock pada Worker Queue Berbasis Cloud

Masalah utama pada worker queue berbasis cloud adalah memastikan cache tidak melayani data usang ketika beberapa worker mengambil item dari antrian yang sama. Untuk menangani cache invalidation dan lock, perlu kombinasi deteksi cache staleness, invalidasi tepat waktu, serta mekanisme locking yang mencegah race condition di antara worker.

Artikel ini membahas pendekatan praktis untuk mengidentifikasi cache usang, memilih pola invalidasi dan locking yang sesuai, serta memonitor operasional lewat metrik observability dan tracing insiden.

Arsitektur referensi: Redis + SQS/Cloud Pub/Sub

Gunakan Redis sebagai cache terdistribusi untuk data hasil pemrosesan queue, sementara queue backend dapat berupa Amazon SQS atau Cloud Pub/Sub bergantung pada preferensi cloud provider. Setiap worker mengambil pesan dari queue, memprosesnya, menyimpan hasil ke cache, dan selanjutnya menginformasikan downstream.

Arsitektur ini rentan terhadap dua isu utama:

• Cache staleness karena data diproses ulang di worker lain setelah cache dihapus atau diupdate.
• Race condition ketika beberapa worker mencoba menulis ke cache atau menandai pekerjaan yang sama.

Solusi terbaik menggabungkan aturan invalidasi eksplisit dengan locking terdistribusi.

Langkah operasional mendeteksi dan mengatasi cache usang

Langkah awal ialah mendeteksi kapan cache menjadi tidak konsisten. Pendekatan operasi:

1. Tag cache berdasarkan ID pekerjaan: Gunakan key Redis berformat job-result:{jobId} dan simpan metadata timestamp pemrosesan.
2. Bandingkan versi data: Saat worker mengambil pesan, baca metadata versi dari payload (misalnya versi data atau timestamp) dan cek apakah cache versi sama. Bila tidak, tanda cache usang.
3. Gunakan TTL konservatif: Set TTL pendek untuk setiap entry cache yang mudah berubah. TTL membantu invalidasi otomatis jika worker gagal menghapus cache manual.

Setelah teridentifikasi, invalidasi bisa dilakukan dengan dua strategi:

• Invalidasi eksplisit: Setelah worker selesai memproses dan menyimpan hasil, hapus entry Redis lama sebelum menulis hasil baru. Ini memerlukan locking agar worker lain tidak mengakses entry sementara dihapus dan diset ulang.
• Penandaan status: Simpan field status di cache seperti processing atau ready. Worker lain mengecek status sebelum mengakses data, memastikan tidak membaca hasil parsial.

Menerapkan pola locking terdistribusi

Locking mencegah beberapa worker memperbarui cache secara simultan. Dua pola yang umum:

Redlock (Redis dengan multiple instance)

Redlock cocok bila Redis cluster tersedia (minimal 5 node). Redlock mengunci key dengan quorum untuk memastikan satu worker mendapat lock. Mekanisme ini kuat untuk kerja lintas regional, tapi implementasinya kompleks. Gunakan library resmi atau dari komunitas yang terpercaya dan pastikan semua node mampu menyepakati lock.

Advisory lock sederhana

Jika hanya satu Redis instance, advisory lock lebih ringan. Gunakan key seperti lock:job-result:{jobId} dengan expirasi singkat (misalnya 30 detik) dan lakukan pola berikut:

function processMessage(jobId, payload) {
  const lockKey = `lock:job-result:${jobId}`;
  if (!redis.set(lockKey, workerId, 'NX', 'PX', 30000)) {
    return; // worker lain masih memegang lock
  }

  try {
    invalidateCache(jobId);
    const result = doWork(payload);
    redis.set(`job-result:${jobId}`, result);
  } finally {
    if (redis.get(lockKey) === workerId) {
      redis.del(lockKey);
    }
  }
}

Pseudocode ini menunjukkan key points:

• Gunakan SET NX PX agar lock otomatis hilang bila worker crash.
• Pastikan hanya owner lock yang menghapusnya.
• Selalu invalidasi cache sebelum menulis hasil baru.

Bila persaingan tinggi, pertimbangkan menambahkan jitter sebelum retry agar backoff tidak bersamaan.

Penanganan retry dan timeout pada queue

Queue cloud seperti SQS/Cloud Pub/Sub memiliki mekanisme retry otomatis. Namun, worker perlu memaksimalkan konsistensi cache:

• Atur visibility timeout dengan bijak: Timeout harus cukup panjang untuk menyelesaikan pekerjaan termasuk invalidasi cache. Terlalu pendek menyebabkan pesan diambil ulang sebelum cache selesai diperbarui.
• Gunakan deduplication ID saat memasukkan hasil cache: Jika pesan diolah ulang karena retry, deduplication mencegah cache ditimpa dengan data lama. Gunakan versi data sebagai bagian deduplication.
• Tangani timeout manual: Jika worker harus exit karena waktu habis, pastikan lock dilepas (via mekanisme auto release) dan log alasan timeout agar bisa dianalisis.

Observability: metrik dan tracing untuk mendeteksi bad data atau deadlock

Pantau metrik berikut:

• Hit rate cache vs. total requests: Turunnya hit rate saat load tinggi bisa jadi indikasi cache tidak konsisten atau invalidasi terlalu agresif.
• Lock wait duration: Monitor rata-rata waktu lock dipegang. Lonjakan bisa menandakan deadlock atau worker lambat.
• Retry count per job: Tingginya jumlah retry seringkali berkaitan dengan timeout queue atau lock yang terus gagal diperoleh.
• Queue age dan message backlog: Indikator apabila worker terhambat karena menunggu lock/global resource.

Pasang tracing (OpenTelemetry, AWS X-Ray, dsb.) untuk mengikuti lifecycle pesan dari penerimaan hingga cache update. Catat event seperti lock acquired, cache invalidated, dan work completed agar bisa menelusuri saat ada data buruk atau deadlock.

Tips tracing insiden dan debugging

Dengan menerapkan deteksi cache usang, invalidasi eksplisit, locking terdistribusi, pengaturan retry/timeout queue, serta metrik observability dan tracing, Anda dapat mempertahankan cache worker queue cloud tetap konsisten sekaligus mudah didiagnosis saat terjadi insiden.