Cara Menjalankan Background Job di Aplikasi Web: Queue, Scheduler, dan Cron

Untuk menjalankan background job di aplikasi web, pertama-tama pisahkan pekerjaannya menjadi dua jenis. Job yang dipicu (mengirim email selamat datang, memproses upload) bisa disimpan ke job queue, sering kali berupa tabel di database Anda, dan ditangani oleh worker dengan percobaan ulang. Job terjadwal (laporan harian, pengingat setiap 15 menit) membutuhkan sesuatu yang berjalan sesuai jadwal: fitur cron dari host, atau scheduler eksternal yang memanggil endpoint yang dilindungi di aplikasi Anda. Selalu buat job aman untuk dijalankan dua kali, catat kegagalan, dan jangan pernah mengandalkan timer di dalam server yang bisa tidur atau restart.

Panduan ini menjelaskan pilihannya, kapan masing-masing cocok, dan cara menyiapkannya dengan pembuat aplikasi AI, termasuk di host yang scale to zero.

Apa yang termasuk background job

Apa pun yang lambat, tidak andal, atau tidak dibutuhkan untuk respons langsung pengguna:

• Mengirim email, notifikasi, dan struk
• Mengubah ukuran gambar, mentranskode video, membuat PDF
• Memanggil API pihak ketiga yang lambat, termasuk model AI untuk tugas panjang
• Mengimpor atau menyinkronkan data dari sistem lain
• Pembersihan malam hari, laporan, dan pengingat

Menjalankan ini di dalam permintaan membuat halaman lambat dan rapuh: jika penyedia email sedang down, pendaftaran pengguna ikut gagal. Memindahkannya ke latar belakang berarti pengguna mendapat respons instan dan job bisa dicoba ulang.

Pilihannya

Tidak ada satu jawaban yang benar. Aplikasi kecil sering hanya membutuhkan queue database plus scheduler eksternal.

Kenapa host yang scale to zero mengubah gambarannya

Banyak host modern menidurkan aplikasi saat tidak ada yang memakainya dan membangunkannya saat ada permintaan berikutnya. Itu menghemat biaya, tetapi server yang tidur tidak menjalankan kode apa pun: timer tidak berjalan dan worker tidak melakukan polling. Di host seperti ini, pekerjaan terjadwal harus dimulai oleh permintaan masuk, dan sumber permintaan yang paling mudah adalah scheduler eksternal. Setiap panggilan akan membangunkan aplikasi (dan sering kali databasenya), sehingga memanggil setiap menit lebih mahal daripada setiap 15 menit. Pilih jadwal yang paling jarang namun tetap memenuhi kebutuhan.

Pola 1: queue job di database

Untuk job yang dipicu:

1. Buat tabel jobs: tipe, payload (JSON), status (pending, running, done, failed), attempts, run_after, last_error, dan timestamp.
2. Saat sesuatu terjadi, sisipkan baris job dalam transaksi yang sama dengan perubahan yang memicunya, sehingga keduanya berhasil atau gagal bersama.
3. Worker mengambil job yang sudah waktunya, menandainya running, menjalankan pekerjaan, lalu menandainya done.
4. Jika gagal, naikkan attempts, atur run_after lebih jauh (misalnya 1, 5, lalu 30 menit), dan simpan errornya. Setelah batas maksimum, tandai failed dan beri peringatan kepada seseorang.

Jika lebih dari satu worker mungkin berjalan bersamaan, job harus diambil dengan aman. Di Postgres, SELECT ... FOR UPDATE SKIP LOCKED memungkinkan setiap worker mengambil baris yang berbeda tanpa bentrok.

Apa yang menjalankan worker? Di server yang selalu menyala, sebuah loop di proses terpisah. Di host scale-to-zero, endpoint terjadwal di Pola 2 bisa memproses sekumpulan job yang sudah waktunya pada setiap panggilan.

Pola 2: scheduler eksternal yang memanggil aplikasi Anda

Untuk job terjadwal:

1. Tambahkan endpoint seperti POST /api/cron/send-reminders.
2. Lindungi: wajibkan token rahasia di header, simpan sebagai secret di kedua sisi, dan tolak apa pun selain itu.
3. Buat endpoint idempotent: menjalankannya dua kali dalam menit yang sama tidak boleh mengirim dua pengingat. Catat apa yang sudah dikirim.
4. Jaga setiap panggilan tetap singkat: proses satu batch (misalnya 100 item) dan biarkan panggilan berikutnya mengambil sisanya.
5. Arahkan scheduler ke endpoint tersebut.

Pilihan scheduler:

• Workflow terjadwal GitHub Actions. Gratis dalam batas penggunaan GitHub. Per September 2026, dokumentasi GitHub menyatakan interval tercepat adalah sekali setiap 5 menit, eksekusi bisa tertunda saat jam sibuk (terutama di awal setiap jam), jadwal menggunakan UTC secara default, dan workflow terjadwal di repositori publik dinonaktifkan setelah 60 hari tanpa aktivitas repositori.
• Layanan cron hosted. Ada banyak layanan yang tugasnya hanya memanggil URL sesuai jadwal. Periksa keandalan, interval minimum, dan notifikasinya sebelum Anda mengandalkannya.
• Scheduler dari penyedia cloud Anda. Jika Anda sudah memakai penyedia cloud besar, pasti ada scheduler terkelola yang bisa memanggil endpoint HTTPS.
• Layanan job atau workflow hosted. Ini menggabungkan penjadwalan, queue, dan retry, lalu memanggil endpoint Anda untuk setiap langkah. Bandingkan harga dan batasnya di situs masing-masing vendor.

Pola 3: biarkan penyedia yang menanganinya

Kadang job latar belakang terbaik adalah tidak membuat job sama sekali:

• Pembayaran. Stripe mencoba ulang pembayaran langganan yang gagal dan mengirim webhook; Anda bereaksi alih-alih melakukan polling. Lihat apa itu webhook.
• Email. Penyedia mengantrekan dan mencoba ulang pengiriman setelah Anda menyerahkan pesannya.
• Pekerjaan AI massal. OpenAI dan Anthropic menyediakan batch API untuk permintaan yang tidak mendesak, yang Anda kirim dan ambil hasilnya nanti.

Prompt untuk pembuat aplikasi AI Anda

Untuk queue:

Tambahkan queue background job menggunakan tabel jobs di database kita (tipe, payload JSON, status, attempts, run_after, last_error). Saat pengguna mendaftar, sisipkan job send_welcome_email dalam transaksi yang sama, alih-alih mengirim email secara inline. Tambahkan fungsi processJobs(limit) yang mengambil job yang sudah waktunya dengan SELECT ... FOR UPDATE SKIP LOCKED, menjalankannya, dan mencoba ulang kegagalan setelah 1, 5, dan 30 menit, lalu menandainya failed setelah 4 percobaan.

Untuk pemicu terjadwal:

Tambahkan POST /api/cron/tick yang dilindungi oleh bearer token dari secret CRON_SECRET; tolak setiap permintaan tanpa token itu. Setiap panggilan menjalankan processJobs(100) dan mengirim pengingat booking yang jatuh tempo dalam 24 jam ke depan yang belum pernah dikirim, sambil mencatat pengingat yang sudah dikirim agar tidak ada yang terkirim dua kali. Kembalikan ringkasan JSON dari apa yang dijalankan. Lalu tulis workflow GitHub Actions yang memanggil endpoint ini setiap 15 menit, dengan membaca URL dan token dari repository secrets.

Kesalahan umum

• Mengandalkan setInterval. Timer ini diam-diam berhenti saat server tidur atau restart, dan berjalan ganda saat dua salinan berjalan.
• Endpoint cron yang tidak dilindungi. Siapa pun yang menemukannya bisa memicu job Anda, atau menaikkan tagihan email Anda.
• Job yang tidak idempotent. Percobaan ulang dan panggilan scheduler ganda pasti terjadi. Rancang untuk itu.
• Tidak ada visibilitas kegagalan. Job yang gagal diam-diam selama seminggu lebih buruk daripada yang gagal dengan jelas. Catat error dan beri peringatan saat kegagalan berulang.
• Proses panjang dalam satu permintaan. Permintaan akan timeout. Proses dalam batch.
• Penjadwalan terlalu sering. Setiap panggilan di host scale-to-zero membangunkan dan menagih aplikasi. Sesuaikan interval dengan kebutuhan nyata.
• Zona waktu. “Jam 9 pagi” berarti hal yang berbeda bagi scheduler Anda (sering UTC) dan bagi pengguna. Simpan waktu dalam UTC dan konversikan per pengguna.
• Secret di file workflow. Simpan token di secret store scheduler. Lihat cara menjaga API key tetap aman.

Daftar periksa

• Pekerjaan lambat sudah dipindahkan dari permintaan pengguna
• Job disimpan secara tahan lama, bukan hanya di memori
• Percobaan ulang dengan jeda yang makin lama dan batas maksimum
• Setiap job aman untuk dijalankan dua kali
• Endpoint terjadwal dilindungi oleh token rahasia
• Setiap eksekusi memproses batch yang terbatas
• Job yang gagal terlihat, dengan peringatan
• Interval jadwal dipilih dengan mempertimbangkan biaya hosting
• Waktu disimpan dalam UTC

Background job di Mythex

Dokumentasi Mythex tidak menjelaskan job terjadwal atau cron, dan aplikasi yang dipublikasikan serta database-nya tidur saat idle dan bangun saat permintaan berikutnya (lihat Hosting limits). Jadi jangan mengandalkan timer di dalam aplikasi Anda. Pendekatan yang bekerja adalah yang dijelaskan di atas: minta agent membuatkan tabel jobs dan endpoint yang dilindungi token, lalu arahkan scheduler eksternal ke URL aplikasi yang sudah dipublikasikan. Simpan token sebagai secret proyek, dan ingat bahwa setiap kali aplikasi dibangunkan, kredit terpakai untuk waktu aplikasi dan database terjaga, jadi pilih interval yang masuk akal. Jika aplikasi Anda membutuhkan backend API untuk ini, resep REST API backend bisa menjadi titik awal, dan cara membangun REST API membahas perancangan endpoint. Jika worker atau bot yang selalu berjalan adalah inti produk Anda, host yang dibuat untuk proses persisten mungkin lebih cocok.

Pertanyaan