Apa kelebihan dan kekurangan BullMQ, dan kapan menggunakannya?

Question

IT Interview Practice · Accepted Answer

BullMQ adalah antrean job untuk Node.js yang menggunakan Redis. Untuk menilai kecocokannya, mulai dari **pekerjaan yang boleh selesai setelah respons HTTP dikirim dan perlu dilacak atau dicoba ulang**.

Misalnya laporan besar. Membuatnya di dalam request dapat membuat pengguna menunggu sampai request mengalami timeout. Antrean memungkinkan aplikasi menerima pekerjaan, mengembalikan ID job, dan memprosesnya secara terpisah.

## 1. Pahami perubahan ketika pekerjaan dipindahkan ke antrean

```text
[User] -> [API: submit job] -> [Redis / BullMQ] -> [Worker]
                |                                   |
          [Return job ID]                       [Saved report]
```

Producer mengirim job; worker mengerjakannya. Pengguna memeriksa progres dan mengunduh laporan yang tersimpan ketika sudah siap.

Laporan tetap membutuhkan waktu pemrosesan. Perbaikannya adalah masa hidup pekerjaan tidak lagi bergantung pada satu request HTTP yang terus terbuka, dan worker dapat dikelola terpisah dari server API.

## 2. Cocokkan manfaat dengan kebutuhan

| Kebutuhan | Kemampuan BullMQ | Hal yang tetap harus ditentukan aplikasi |
| --- | --- | --- |
| Pulih dari kegagalan sementara | Percobaan ulang dengan jeda bertahap | Error mana yang layak dicoba ulang dan kapan berhenti. |
| Berjalan nanti atau sesuai jadwal | Job tertunda dan penjadwalan | Ketepatan waktu yang dibutuhkan dan perilaku setelah layanan berhenti. |
| Mengendalikan beban pemrosesan | Konkurensi dan pembatasan laju | Batas aman bagi database dan layanan eksternal. |
| Menambah kapasitas pekerjaan latar belakang | Worker tambahan | Apakah dependensi berikutnya mampu menerima beban tambahan. |

Untuk laporan tadi, fitur ini menghindarkan tim dari membangun sendiri pengelolaan status job dan percobaan ulang. Fitur tersebut juga menyediakan informasi status untuk progres dan penyelidikan kegagalan. Penambahan worker bermanfaat selama mempercepat penyelesaian tanpa membebani dependensi secara berlebihan.

## 3. Pahami tanggung jawab utama atas kebenaran hasil

Worker dapat menyimpan laporan lalu gagal sebelum menandai job selesai. Percobaan ulang kemudian dapat mengulang pekerjaan. Pola yang sama lebih serius untuk tindakan seperti menagih pembayaran atau mengirim notifikasi.

Gunakan identitas bisnis yang stabil untuk pekerjaan yang diminta. Pengulangan identitas tersebut harus menggunakan kembali atau mengganti hasil yang dimaksud secara aman, bukan menghasilkan efek bisnis tambahan. Inilah idempotensi. Untuk efek eksternal, gunakan dukungan penyedia jika tersedia dan rekonsiliasi hasil yang belum pasti. [Job idempoten](https://docs.bullmq.io/patterns/idempotent-jobs).

Jika penyimpanan record database juga harus membuat job, perhatikan celah di antara kedua penulisan. Outbox mencatat instruksi dalam transaksi yang sama dengan record bisnis; publisher kemudian mengirimkannya ke antrean. Pengiriman dapat berulang, sehingga worker tetap membutuhkan idempotensi.

## 4. Masukkan operasional Redis dan worker dalam biaya

Redis menyimpan pekerjaan yang menunggu, sehingga persistensi, kebijakan memori, dan rencana pemulihannya penting. Terapkan kebijakan noeviction untuk antrean: menghapus key diam-diam untuk mengosongkan memori tidak cocok bagi job yang harus tetap tersedia. Uji pemulihan; jangan menganggap keamanan saat aplikasi dimulai ulang mencakup seluruh kegagalan Redis. [Panduan produksi](https://docs.bullmq.io/guide/going-to-production).

Simpan file laporan besar pada penyimpanan yang sesuai dan masukkan referensinya ke job. Tentukan masa penyimpanan catatan job selesai dan gagal agar penggunaan Redis terkendali.

Pemrosesan CPU yang berat dapat memblokir event loop worker dan mengganggu perpanjangan lock. Job kemudian dapat dianggap macet dan diproses kembali. Gunakan worker thread atau processor terisolasi yang sesuai untuk beban tersebut, dan pantau job macet. [Job macet](https://docs.bullmq.io/guide/jobs/stalled).

## 5. Berikan rekomendasi sesuai kondisi

- Pilih BullMQ ketika aplikasi Node.js membutuhkan pekerjaan latar belakang yang dapat dipantau, percobaan ulang, serta worker yang dapat ditambah terpisah, dan tim mampu mengoperasikan Redis dengan andal.
- Pertahankan kesederhanaan tindakan lokal yang ringan jika tidak membutuhkan pelacakan tahan lama atau eksekusi independen.
- Evaluasi log event yang tahan lama jika kebutuhan utamanya adalah pemutaran ulang jangka panjang oleh beberapa consumer independen, bukan penyelesaian tugas antrean.

Untuk contoh laporan, uji kegagalan dependensi, worker yang gagal setelah hasil tersimpan, dan pemulihan setelah gangguan. Pastikan pengguna melihat status yang dapat dipercaya dan percobaan ulang tidak menciptakan hasil yang saling bertentangan.

**Ingat:** BullMQ menyediakan koordinasi job. Aplikasi menjamin kebenaran bisnis, dan tim tetap bertanggung jawab atas operasional antrean.

Kebutuhan	Kemampuan BullMQ	Hal yang tetap harus ditentukan aplikasi
Pulih dari kegagalan sementara	Percobaan ulang dengan jeda bertahap	Error mana yang layak dicoba ulang dan kapan berhenti.
Berjalan nanti atau sesuai jadwal	Job tertunda dan penjadwalan	Ketepatan waktu yang dibutuhkan dan perilaku setelah layanan berhenti.
Mengendalikan beban pemrosesan	Konkurensi dan pembatasan laju	Batas aman bagi database dan layanan eksternal.
Menambah kapasitas pekerjaan latar belakang	Worker tambahan	Apakah dependensi berikutnya mampu menerima beban tambahan.

1. Pahami perubahan ketika pekerjaan dipindahkan ke antrean

2. Cocokkan manfaat dengan kebutuhan

3. Pahami tanggung jawab utama atas kebenaran hasil

4. Masukkan operasional Redis dan worker dalam biaya

5. Berikan rekomendasi sesuai kondisi

Pertanyaan terkait