Tiga Hal yang Langsung Saya Terapkan Setelah Paham Kenapa Laravel Queues Itu Bukan Fitur Opsional

Saya cukup lama menghindari Laravel queues. Bukan karena tidak tahu fiturnya ada, tapi karena merasa proyek saya "belum perlu."

Itu keputusan yang belakangan saya sesali.

Bukan karena queue adalah teknologi yang keren untuk dikuasai. Tapi karena tanpa queue, saya tanpa sadar membangun API yang membuat user menunggu hal-hal yang seharusnya bisa dikerjakan di background.

Kenapa saya terlambat pakai queue

Di awal karier backend, logika saya sederhana: request masuk, proses, selesai, kirim response. Alur yang bersih dan mudah di-trace.

Yang tidak saya sadari: alur itu jadi masalah saat ada task yang butuh waktu tapi user tidak perlu menunggu hasilnya di response yang sama. Kirim email konfirmasi setelah registrasi? Kenapa harus bikin user stare at loading screen selama 2-3 detik sampai SMTP selesai? Generate laporan PDF bulanan? Kenapa request harus blocked sampai file selesai dibuat?

Sync processing itu tidak salah untuk hal-hal yang hasilnya memang dibutuhkan sekarang. Tapi banyak task di aplikasi nyata yang hasilnya tidak perlu ada di response yang sama. Itu yang lama tidak saya sadari.

Perubahan pertama: email dan notifikasi keluar dari request cycle

Ini yang paling langsung terasa dampaknya. Semua endpoint yang mengirim email, dari welcome message, password reset, sampai invoice notification, saya pindahkan ke queue.

Hasilnya langsung kelihatan: response time di endpoint-endpoint tersebut turun drastis. User tidak lagi nunggu proses SMTP selesai. Kalau email server sedang lambat atau timeout, itu tidak lagi jadi blocker buat user.

Implementasinya di Laravel cukup straightforward. Buat Job class, tentukan apa yang harus dikerjakan di dalam handle(), dispatch ke queue. Selesai. Yang lebih penting dari kodenya adalah mindset-nya: pisahkan "tugas yang hasilnya butuh sekarang" dari "tugas yang cukup dikerjakan nanti."

Email hampir selalu masuk kategori kedua.

Perubahan kedua: heavy processing tidak lagi blocking

Ada fitur di salah satu proyek yang generate laporan bulanan dalam bentuk Excel. Awalnya sinkronus: user klik tombol, server proses, kadang timeout di tengah jalan. User refresh, tidak tahu apakah laporan sedang dibuat atau gagal.

Sekarang: user klik tombol, langsung dapat response "laporan sedang diproses, kami kirim via email jika sudah siap." Proses yang sama persis di backend, tapi user experience-nya berbeda jauh. Tidak ada timeout, tidak ada loading tanpa kepastian.

Prinsipnya sederhana: kalau sesuatu butuh lebih dari beberapa detik dan user tidak butuh hasilnya di layar yang sama, itu kandidat kuat untuk dipindah ke queue. Tidak ada alasan membuat user menunggu sesuatu yang bisa dikerjakan di background.

Perubahan ketiga: retry logic sudah built-in, tidak perlu ditulis manual

Ini yang tidak saya kira bakal jadi game-changer, tapi ternyata sangat berguna di production.

Sebelumnya, kalau ada proses yang gagal karena API eksternal timeout atau database error sementara, saya harus handle sendiri: tangkap exception, putuskan mau coba lagi atau tidak, log errornya, simpan status yang tepat. Kodenya panjang dan rawan edge case.

Dengan queue, Laravel sudah punya mekanisme retry bawaan. Definisikan berapa kali job boleh diretry, berapa detik delay antar percobaan, dan apa yang harus terjadi kalau semua retry habis. Semuanya deklaratif di level Job class, tidak perlu menulis retry logic dari nol di setiap tempat yang butuh.

Untuk job yang hasilnya critical, ini bukan fitur opsional. Ini safety net yang seharusnya ada sejak awal.

Hal penting yang tetap perlu diperhatikan

Queue bukan solusi untuk semua masalah performance. Ada banyak hal yang memang harus sinkronus karena user butuh hasilnya di saat itu juga: validasi form, pengecekan stok real-time, kalkulasi yang langsung tampil di UI. Kalau dipindah ke queue, flow-nya justru rusak.

Queue juga butuh monitoring. Kalau job gagal terus dan tidak ada yang notice, pengguna bisa kena dampaknya tanpa ada yang tahu. Laravel Horizon sangat membantu untuk ini, tapi minimal pastikan ada notifikasi ketika failed jobs menumpuk.

Satu hal lagi yang sering terlewat: usahakan job bersifat idempotent kalau memungkinkan. Artinya, kalau job dijalankan dua kali karena retry, hasilnya sama dan tidak ada efek samping yang digandakan. Untuk kirim email misalnya, pastikan tidak terkirim dua kali ke user yang sama.

Mulai dari yang paling mudah

Kalau masih ragu harus mulai dari mana, jawaban paling praktis: mulai dari email.

Hampir setiap aplikasi punya fitur kirim email. Hampir selalu bisa dipindah ke queue tanpa mengubah apapun di UI atau business logic. Dan dampaknya langsung terasa di response time.

Setelah itu terasa bedanya, giliran melihat proses lain mana yang bisa dipindah. Bukan karena queue adalah tujuan, tapi karena memindahkan hal yang tepat ke background adalah cara membuat aplikasi yang lebih responsif tanpa harus refactor besar-besaran.

Queue bukan fitur advanced. Itu cara berpikir tentang kapan sesuatu perlu dikerjakan, dan apakah user memang perlu menunggu untuk itu.