Untuk menjaga konten yang di-render oleh Nuxt.js tetap cepat dan konsisten, Anda perlu menangani cache SSR sekaligus bekerja dengan queue worker terkoordinasi. Tujuannya adalah menghindari cache usang dan job duplikat saat deploy berganda, memastikan state backend tidak bentrok.

Artikel ini menjelaskan arsitektur praktis: cache layer untuk hasil SSR, queue background untuk pekerjaan stateful, mekanisme locking Redis agar job tidak tumpang tindih di worker, serta langkah monitoring dan pemulihan ketika konsistensi data terganggu.

Arsitektur Kunci: Cache SSR dengan Queue Terkoordinasi

Nuxt.js biasanya menghasilkan HTML server-side untuk permintaan publik. Jika Anda meng-cache hasil SSR, perlu pastikan invalidasi cache dan queue background (mis. sinkronisasi data) berjalan sinkron. Pendekatannya: setiap permintaan yang memodifikasi data men-trigger job queue, job akan memperbarui cache dan melepaskan lock sebelum job berikutnya mengambil alih.

Lapisan Cache SSR dan Invalidasi

Pertahankan cache per-route atau per-entity di Redis dengan metadata timestamp. Setelah job queue menyelesaikan mutasi data, job tersebut mem-publish channel invalidasi atau memperbarui hash cache untuk nilai baru.

Contoh aliran:

  1. Permintaan mutasi menulis ke database & menambahkan payload ke queue.
  2. Worker dequeue memperbarui data & menghasilkan snapshot bisnis.
  3. Worker memperbarui cache SSR (misalnya menyimpan kembali HTML atau data store) lalu menghapus entry lama.

Gunakan TTL moderat plus header stale-while-revalidate agar permintaan pertama setelah invalidasi tetap menerima response lama sambil memicu regenerasi di background.

Strategi Cache Invalidation

Salah satu pola yang efektif: cache key berbasis identifier dan versi (mis. article:123:v5). Queue worker memperbarui versi saat selesai, dan Nuxt middleware menolak cache versi lama. Gunakan pub/sub Redis untuk mem-broadcast invalidasi agar instance Nuxt yang lain juga menghapus cache.

Queue Worker Dedup dan Locking

Queue worker menerima job dari Redis/Beats (mis. BullMQ). Anda harus mencegah job duplikat ketika deploy berganda memulai worker baru.

Dedup dengan Hash Job

Setiap job harus membawa fingerprint (mis. sha256(entityId + type + payloadHash)). Sebelum push ke queue, periksa Redis SET atau Sorted Set untuk memeriksa fingerprint yang sedang diproses atau baru saja selesai.

const fingerprint = generateFingerprint(payload);
if (await redis.sismember('jobs:processing', fingerprint)) {
  return; // sudah dalam antrean
}
await redis.sadd('jobs:processing', fingerprint);
await queue.add({ fingerprint, payload });

Worker menghapus fingerprint dari SET setelah job selesai. Jika job gagal, gunakan TTL untuk menghapus fingerprint otomatis atau insert ulang job setelah backoff.

Koordinasi Locking Redis

Gunakan lock Redis (SETNX dengan expire) untuk memastikan hanya satu worker yang memproses job untuk entity tertentu, terutama bila job memperbarui cache SSR.

const lockKey = `lock:entity:${entityId}`;
const lock = await redis.set(lockKey, workerId, 'NX', 'PX', 30000);
if (!lock) {
  // worker lain memegang lock
  return;
}
try {
  await updateStorage();
  await invalidateCache();
} finally {
  const currentOwner = await redis.get(lockKey);
  if (currentOwner === workerId) {
    await redis.del(lockKey);
  }
}

Naqsozh, lock harus memiliki expire agar deploy lama tidak mengunci sistem selamanya. Worker juga dapat memperbarui expire secara periodik jika job berjalan lama.

Monitoring dan Pemantauan

Untuk menjaga konsistensi, fokus pada metrik-metrik berikut:

  • Cache hit/miss ratio per route atau grup endpoint siaga.
  • Latency invalidasi cache dari job queue hingga cache ter-refresh.
  • Queue depth dan waktu tunggu job (queue.age).
  • Worker error rate serta retry count.
  • Lock contention (berapa sering lock ditolak).

Gunakan dashboard seperti Grafana dengan exporter Redis + Bull metrics. Tambahkan alert ketika cache hit ratio turun drastis atau backlog job menumpuk, lalu pantau log worker untuk melihat error stack.

Langkah Operasional Saat Konsistensi Data Terganggu

Jika data tak sinkron, ikuti langkah berikut:

  1. Verifikasi queue worker log: cari job yang gagal atau job stuck pada state "active" terlalu lama.
  2. Periksa lock Redis: lock yang tidak dilepas menunjukkan worker mati atau deploy terputus; manual release mungkin diperlukan.
  3. Trigger ulang job dedup secara manual melalui script CLI dengan fingerprint yang rusak.
  4. Validasi cache: bersihkan cache (per route) dan pastikan job background mem-publish invalidasi terbaru.
  5. Periksa metrik hit/miss; jika hit turun, analisis apakah cache key sudah berubah karena versi baru.

Untuk pemulihan otomatis, sediakan job requeue bermode "reconcile" yang memeriksa perbedaan antara database dan cache SSR. Job ini juga dapat memperbarui fingerprint untuk menghindari dedup blocking.

Ringkasan dan Pertimbangan

Solusi Nuxt.js terkoordinasi membutuhkan kombinas pengawasan cache SSR, worker queue, dedup fingerprint, dan locking Redis. Trade-off utamanya adalah tambahan kompleksitas dan latensi karena invalidasi asinkron, namun hasilnya: data konsisten, job tidak duplikat, dan pengalaman pengguna tetap responsif.

Selalu sertakan monitoring berbasis metrik dan alert untuk mendeteksi anomali. Debugging rutin sebaiknya dimulai dari log worker, pipeline invalidasi cache, hingga state lock di Redis.