Ringkasan Langsung

Pull request untuk queue worker, cache, dan operasi konsisten harus menjawab: apakah job queue memproses data secara idempoten, apakah cache tidak menghasilkan informasi usang, dan apakah locking serta retry di-handle dengan benar. Praktek ini menempatkan observability, dokumentasi state, dan mitigasi potensial sebagai langkah wajib agar reviewer dapat memberikan tinjauan bermakna.

Video "Pull Requests are Free Puppies" mengingatkan bahwa PR bukan tugas formal; itu kesempatan kolaborasi. Jadi jangan sekadar checklist formal—gunakan setiap PR untuk memvalidasi asumsi teknis penting.

1. Memahami PR sebagai Kolaborasi Teknik

Ketimbang melihat PR sebagai tugas yang harus dicentang, perlakukan PR sebagai percakapan teknis. Sebelum memeriksa detail implementasi, baca penjelasan perubahan: mengapa perubahan diperlukan, bagaimana alur data berubah, dan apa dampaknya terhadap konsistensi. Jika konteks hilang, minta penulis menambahkan catatan atau diagram singkat, karena reviewer tidak punya akses ke pemikiran penulis.

Dalam transportasi queue worker, cache, atau locking, validasi harus fokus pada side effect. Jangan hanya memeriksa penamaan fungsi—perhatikan asumsi state dan kondisi balapan (race conditions) yang dihadapi di produksi.

2. Checklist Review Queue Worker dan Cache

Gunakan checklist ini sebagai landasan untuk menilai PR dengan tujuan teknis:

  • Job Idempotency: Apakah worker memeriksa operasi yang sudah selesai atau duplikat sebelum mengeksekusi? Cari mekanisme deduplikasi atau flag selesai.
  • Boundary Input: Pastikan job memvalidasi payload dan tidak langsung memproses data mentah yang bisa memicu exception tak tertangani.
  • Locking/Concurrency: Apakah ada distribusi lock (Redis lock, advisory lock DB) untuk operasi kritis? Lihat apakah timeout lock sesuai dan rilis terjadi dalam finally block.
  • Cache Invalidation: Saat update data utama, apakah cache dihapus atau diperbarui secara konsisten? Review urutan: tulis ke DB dulu baru invalidasi cache, atau gunakan pendekatan background refresh.
  • Retry yang Terkontrol: Apakah retry job berhenti ketika data sudah referentially consistent? Pastikan exponential backoff, deserialisasi ulang, dan batas maksimal ditentukan.
  • Logging/Tracing: Apakah job menulis trace ID, state perubahan, dan status akhir ke log/observability?
  • Dokumentasi State: Catat state apa yang berubah dan bagaimana konsistensinya diuji.

Contoh Implementasi Queue Worker

Perhatikan contoh potongan pseudocode worker:

async function processOrder(orderId) {
  const lock = await redis.acquireLock(`order:${orderId}`, { ttl: 30_000 });
  if (!lock) return;
  try {
    const order = await db.orders.findOne(orderId);
    if (order.processed) return;
    await db.orders.update(orderId, { status: 'processing' });
    await cache.invalidate(`order:${orderId}`);
    await paymentGateway.capture(orderId);
    await db.orders.update(orderId, { status: 'completed' });
  } finally {
    await lock.release();
  }
}

Reviewer harus memastikan setiap langkah memiliki fallback, dan observability menyebutkan apakah lock gagal diperoleh atau transaksi gagal.

3. Observability dan Dokumentasi Perubahan State

Observability membuat issue queue worker dan cache nyata dalam produksi. Jika job gagal, log harus menyertakan trace ID, job ID, dan alasan kegagalan.

  • Metrics: Pantau latency job, jumlah retry, cache hit/miss, dan lock wait time.
  • Alerting: Buat alert bila job retry berulang, cache invalidation terlalu sering, atau lock take time terlalu lama.
  • Audit State: Dokumentasikan state transition baru dalam PR—misal tabel/field yang berubah, cache key yang disingkirkan, atau side effect eksternal.

Catat juga di dokumentasi tim bahwa PR tertentu memperkenalkan konsistensi baru; review selanjutnya bisa merujuk pada catatan ini.

4. Contoh Masalah Umum dan Mitigasi

Berikut isu yang sering muncul dan cara mitigasinya:

  • Retry job tanpa idempotensi: Bisa menghasilkan duplikat. Mitigasi: tambah deduplikasi via tokens, periksa status sebelum aksi permanen.
  • Race Cache dan DB: Cache invalidation terlambat menyebabkan data usang. Mitigasi: lakukan write-through atau background refresh setelah update.
  • Lock tidak dilepas: Locking yang bocor menghentikan worker lain. Mitigasi: gunakan finally block dan monitor lock TTL.

Reviewer harus menguji mental model ini dengan pertanyaan: "Bagaimana sistem bereaksi bila job diproses ulang?" dan "Apakah cache akan menampilkan data yang salah selama window tertentu?"

5. Checklist Penguatan PR

Berikut checklist yang bisa ditambahkan di komentar PR:

  1. Deskripsi PR menjelaskan state baru/berubah, cache key yang terpengaruh, dan locking yang digunakan.
  2. Job queue menyertakan retry/backoff dan mencatat state final (sukses/gagal) serta identitas job.
  3. Cache invalidation ditempatkan setelah persistensi data, atau dilakukan dengan strategi refresh yang terukur.
  4. Observability (log/tracing/metrics) menjelaskan failure mode utama.
  5. Test cover regression: unit test worker, integration test cache behavior, dan e2e scenario untuk konsistensi.
  6. Dokumentasi internal menyebutkan perbedaan state atau requirement baru (misal dependensi event external) agar tim lain tahu perubahan per-scope.

Penutup

Checklist ini menjaga PR fokus pada queue worker, cache, dan konsistensi state, sejalan dengan pesan video: PR adalah kesempatan mengecek asumsi teknis, bukan sekadar formalitas. Dengan langkah review yang jelas, observability, dan dokumentasi yang memadai, reviewer dapat mengidentifikasi risiko seperti retry tidak terkontrol, race condition, atau cache stale sebelum kode menyebar ke produksi.