Kepiye ngoordinasi cron job ing sawetara node NestJS?

Question

IT Interview Practice · Accepted Answer

Pisanan temtokake tegese “mung siji node nglakokake cronjob”. **Nyegah eksekusi bebarengan lan nyegah efek bisnis bola-bali iku syarat beda.** Scheduler bebarengan ngatur eksekusi; operasine dhewe kudu aman sawise crash lan dicoba maneh.

Bayangna job faktur saben dina sing dipasang ing telung node NestJS. Gaweyan kudu mlaku manut jadwal tanpa nggawe faktur maneh nalika worker restart.

## 1. Pahami sebabe kabeh node miwiti tugas

Saben instance aplikasi ndhaptar callback cron dhewe. Nalika wektu jadwal tekan, saben node bisa miwiti kanthi mandiri:

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

Flag isRunning lokal mung ana ing siji proses. waitForCompletion NestJS bisa nyegah callback tumpang tindih ing instance kasebut, nanging ora koordinasi karo node liyane. Nambah flag padha ing telung node tetep ninggalake telung keputusan kapisah. [Penjadwalan NestJS](https://docs.nestjs.com/techniques/task-scheduling).

Mula perlu papan bebarengan kanggo mutusake gaweyan apa sing ana lan sapa sing oleh ngolah.

## 2. Pilih model koordinasi

| Kahanan | Pilihan sing dievaluasi | Tanggung jawab sing isih ana |
| --- | --- | --- |
| Platform wis nyedhiyakake job terjadwal | Jadwalake ing njaba instance web | Atur tumpang tindih, pamulihan, lan jadwal sing kliwatan. |
| Tim wis ngoperasikake BullMQ | Job Scheduler bebarengan lan antrean khusus | Atur konkurensi bebarengan lan retry aman. |
| Tugas kudu tetep ing node aplikasi | Lock utawa lease bebarengan | Tangani kepemilikan, kadaluwarsa, lan worker lawas kanthi bener. |

Kanggo faktur, yen Redis lan BullMQ wis ana, scheduler bebarengan nganggo ID stabil dadi calon praktis. Pisahake jadwal saka worker supaya nambah node web ora nggawe jadwal mandiri.

Ing versi BullMQ sing ndhukung, atur global concurrency antrean khusus dadi siji. Iki matesi job aktif ing kabeh worker; local concurrency siji saben worker isih ngidini sawetara worker nglakokake job beda. [Global concurrency](https://docs.bullmq.io/guide/queues/global-concurrency).

Temtokake yen gaweyan wingi isih mlaku: ngenteni, ngliwati, utawa nggabungake jadwal. Temtokake zona wektu lan apa tanggal bisnis sing kliwatan kudu digarap sawise downtime.

## 3. Lindhungi faktur, ora mung job

Upamane worker nggawe faktur banjur crash sadurunge nyathet job rampung. Pamulihan bisa nglakokake job maneh sanajan faktur wis ana.

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

Gunakake kunci bisnis stabil, kayata pelanggan lan periode tagihan. Kanggo database lokal, unique constraint lan transaksi bisa nyambungake nggawe faktur karo record eksekusi rampung. Retry banjur nemokake asil sing wis ana, ora nggawe faktur liyane.

Kanggo panyedhiya njaba, gunakake idempotency key yen didhukung lan cocokake asil sing durung mesthi. ID job antrean utawa record job sing disimpen wae dudu jaminan permanen yen tumindak bisnis ora bisa mbaleni. [Job idempoten](https://docs.bullmq.io/patterns/idempotent-jobs).

## 4. Ngerti apa sing bisa lan ora bisa dijamin lock

Lock bebarengan kudu dijupuk atomik. Gunakake token kepemilikan, kadaluwarsa, lan pembaruan; ngeculake mung yen token isih cocog. Yen ora, worker lawas bisa ngeculake lock worker anyar.

Kadaluwarsa nggawe kasus liyane: worker sing mandheg sedhela urip maneh sawise lease entek, nalika worker anyar wis mlaku. Panulisan penting bisa butuh fencing token, angka kepemilikan sing terus mundhak lan dipriksa tujuan supaya worker lawas ditolak. Timeout dawa wae ora ngilangi risiko iki.

Yen koordinasi ora kasedhiya, temtokake apa tugas kudu ngenteni tinimbang mlaku tanpa kepemilikan. Kanggo gaweyan sing duwe akibat penting, ngenteni kerep luwih aman.

## 5. Priksa kasus kegagalan

Uji sawetara node, crash sawise nggawe faktur, jeda luwih dawa tinimbang lease, koneksi Redis ilang, lan rolling deployment. Cathet tanggal bisnis, worker, upaya, lan asil supaya upaya bola-bali bisa dibedakake saka efek bola-bali.

**Elinga:** koordinasi jadwal → matesi eksekusi bebarengan → nggawe tumindak bisnis aman dicoba maneh → nguji pamulihan. “Siji job aktif” wae durung mbuktekake mung siji efek bisnis.

Kahanan	Pilihan sing dievaluasi	Tanggung jawab sing isih ana
Platform wis nyedhiyakake job terjadwal	Jadwalake ing njaba instance web	Atur tumpang tindih, pamulihan, lan jadwal sing kliwatan.
Tim wis ngoperasikake BullMQ	Job Scheduler bebarengan lan antrean khusus	Atur konkurensi bebarengan lan retry aman.
Tugas kudu tetep ing node aplikasi	Lock utawa lease bebarengan	Tangani kepemilikan, kadaluwarsa, lan worker lawas kanthi bener.

1. Pahami sebabe kabeh node miwiti tugas

2. Pilih model koordinasi

3. Lindhungi faktur, ora mung job

4. Ngerti apa sing bisa lan ora bisa dijamin lock

5. Priksa kasus kegagalan

Pitakon sing gegandhengan