Bagaimana mengoordinasikan cron di beberapa node NestJS?

Question

IT Interview Practice · Accepted Answer

Tentukan dahulu arti “cronjob hanya dijalankan satu node”. **Mencegah eksekusi bersamaan dan mencegah efek bisnis berulang adalah dua kebutuhan berbeda.** Penjadwal bersama mengoordinasikan eksekusi; operasinya sendiri harus tetap aman setelah proses gagal dan dicoba ulang.

Bayangkan tugas pembuatan faktur harian yang dipasang pada tiga node NestJS. Pekerjaan terjadwal harus berjalan tanpa membuat faktur tambahan ketika worker dimulai ulang.

## 1. Pahami mengapa semua node memulai tugas

Setiap instance aplikasi mendaftarkan callback cron sendiri. Pada waktu yang dijadwalkan, masing-masing dapat mulai secara independen:

```text
00:00 -> Node A -> invoice task
      -> Node B -> invoice task
      -> Node C -> invoice task
```

Flag isRunning lokal hanya ada dalam satu proses. waitForCompletion milik NestJS dapat mencegah callback yang bertumpuk pada instance tersebut, tetapi tidak mengoordinasikan node lain. Menambahkan flag yang sama pada ketiga node tetap menghasilkan tiga keputusan terpisah. [Penjadwalan NestJS](https://docs.nestjs.com/techniques/task-scheduling).

Karena itu, dibutuhkan tempat bersama untuk menentukan pekerjaan yang tersedia dan siapa yang boleh memprosesnya.

## 2. Pilih model koordinasi

| Situasi | Pilihan yang perlu dievaluasi | Tanggung jawab yang tetap ada |
| --- | --- | --- |
| Platform sudah menyediakan tugas terjadwal | Jalankan penjadwalan di luar instance web | Atur eksekusi bertumpuk, pemulihan, dan jadwal yang terlewat. |
| Tim sudah mengoperasikan BullMQ | Job Scheduler bersama dan antrean khusus | Atur konkurensi bersama serta percobaan ulang yang aman. |
| Tugas harus tetap berada pada node aplikasi | Lock atau lease bersama | Tangani kepemilikan, kedaluwarsa, dan worker lama dengan benar. |

Untuk contoh faktur, jika Redis dan BullMQ sudah tersedia, penjadwal bersama dengan ID penjadwal yang stabil merupakan pilihan praktis. Pisahkan jadwal dari worker agar penambahan node web tidak menciptakan jadwal independen.

Pada versi BullMQ yang mendukungnya, tetapkan konkurensi global antrean khusus menjadi satu. Ini membatasi job aktif di seluruh worker; konkurensi lokal satu pada setiap worker masih memungkinkan beberapa worker menjalankan job berbeda. [Konkurensi global](https://docs.bullmq.io/guide/queues/global-concurrency).

Tentukan tindakan jika pekerjaan kemarin masih berjalan: menunggu, melewati, atau menggabungkan jadwal. Tetapkan zona waktu dan apakah tanggal bisnis yang terlewat harus diproses setelah layanan berhenti.

## 3. Lindungi faktur, bukan hanya job

Misalnya, worker membuat faktur lalu gagal sebelum mencatat penyelesaian job. Saat pemulihan, job mungkin dijalankan lagi meskipun faktur sudah ada.

```text
[Create invoice] -> [Crash before completion]
                              |
                            [Retry]
                              |
                  [Same business key: reuse result]
```

Gunakan kunci bisnis yang stabil, misalnya pelanggan ditambah periode tagihan. Untuk pekerjaan pada database lokal, constraint unik dan transaksi dapat menghubungkan pembuatan faktur dengan catatan penyelesaian proses. Percobaan ulang kemudian menemukan hasil yang sudah ada, bukan membuat faktur baru.

Untuk penyedia eksternal, gunakan kunci idempotensi jika didukung dan rekonsiliasi hasil yang belum pasti. ID job antrean atau catatan job yang disimpan saja bukan jaminan permanen bahwa tindakan bisnis tidak dapat berulang. [Job idempoten](https://docs.bullmq.io/patterns/idempotent-jobs).

## 4. Pahami jaminan dan batasan lock

Lock bersama harus diperoleh secara atomik. Gunakan token kepemilikan, waktu kedaluwarsa, dan perpanjangan; lepaskan hanya ketika token masih cocok. Jika tidak, worker lama dapat melepaskan lock milik worker baru.

Kedaluwarsa menimbulkan kasus lain: worker yang sempat berhenti melanjutkan setelah lease-nya habis, sementara worker baru sudah berjalan. Penulisan penting mungkin memerlukan fencing token, yaitu nomor kepemilikan yang terus meningkat dan diperiksa tujuan penulisan untuk menolak worker lama. Menetapkan timeout panjang saja tidak menghilangkan risiko ini.

Jika koordinasi tidak tersedia, tentukan apakah tugas harus menunggu alih-alih berjalan tanpa kepemilikan. Untuk pekerjaan yang berdampak penting, menunggu sering menjadi pilihan lebih aman.

## 5. Verifikasi skenario kegagalan

Uji beberapa node, kegagalan setelah pembuatan faktur, jeda lebih lama dari lease, putusnya koneksi Redis, dan deployment bergilir. Catat tanggal bisnis, worker, percobaan, serta hasil agar percobaan berulang dapat dibedakan dari efek berulang.

**Ingat:** koordinasikan jadwal → batasi eksekusi bersama → buat tindakan bisnis aman dicoba ulang → uji pemulihan. “Satu job aktif” saja tidak membuktikan bahwa efek bisnis terjadi tepat satu kali.

Situasi	Pilihan yang perlu dievaluasi	Tanggung jawab yang tetap ada
Platform sudah menyediakan tugas terjadwal	Jalankan penjadwalan di luar instance web	Atur eksekusi bertumpuk, pemulihan, dan jadwal yang terlewat.
Tim sudah mengoperasikan BullMQ	Job Scheduler bersama dan antrean khusus	Atur konkurensi bersama serta percobaan ulang yang aman.
Tugas harus tetap berada pada node aplikasi	Lock atau lease bersama	Tangani kepemilikan, kedaluwarsa, dan worker lama dengan benar.

1. Pahami mengapa semua node memulai tugas

2. Pilih model koordinasi

3. Lindungi faktur, bukan hanya job

4. Pahami jaminan dan batasan lock

5. Verifikasi skenario kegagalan

Pertanyaan terkait