SMTP connection memakan 1-2 detik per email. Kalau Anda pakai Mail::send secara synchronous, setiap email menambah 1-2 detik ke response time aplikasi Anda. Queue email ada benaknya, tapi tidak untuk semua kasus. Artikel ini kasih kerangka keputusan yang jelas: kapan queue wajib, kapan Mail::send masih cukup, dan bagaimana mengukur kapan Anda harus switch.
Email tidak terkirim. Atau lebih tepatnya: email-nya sudah terkirim, tapi pengguna Anda protes karena mereka tidak dapat apa-apa.
Ini laporan yang sering masuk di channel support aplikasi yang sedang berkembang. Biasanya setelah developer cek log SMTP, konfigurasi Mailgun atau provider lain, semua terlihat normal. Email memang dikirim. Tiba di server tujuan. Tapi pengguna bilang tidak ada.
Masalahnya jarang di konfigurasi. Masalahnya ada di cara email itu dikirim.
Daftar Isi
Kenapa Email Laravel Anda Terasa Lambat Padahal SMTP Sudah Cepat?
SMTP provider yang bagus, apakah itu Gmail, SendGrid, atau KIRIM.EMAIL Dev, punya server yang responsive. Connection time yang normal untuk satu email adalah sekitar 1-2 detik. Ini bukan angka sembarangan. Ini pengukuran dari developer yang mengalami masalah yang sama di forum yang berbeda, secara independent.
Sekarang bayangkan skenario ini: aplikasi Anda kirim email welcome ke 50 pengguna baru sekaligus. Mail::send dipanggil 50 kali secara synchronous dalam satu request. Setiap panggilan tunggu SMTP handshake selesai. Total tambahan response time: 50-100 detik.
Tentu saja tidak ada aplikasi yang memanggil Mail::send 50 kali sekaligus dalam satu request untuk email welcome. Tapi untuk skenario yang lebih kecil, 5 email OTP atau 10 email notifikasi order, angka-angka ini tetap signifikan. Terutama kalau email bukan bagian kritis dari user flow yang sedang mereka jalankan.
Ini yang sering tidak ditangkap tutorial queue email di luar sana. Queue memang membikin aplikasi lebih cepat. Tapi tidak semua email perlu di-queue, dan tidak semua aplikasi butuh pengorbanan kompleksitas itu.
Kapan Mail::send Sudah Cukup untuk Aplikasi Anda?
Mail::send secara synchronous bukan pilihan yang salah. Ini pilihan yang tepat untuk banyak kasus. Yang perlu Anda tentukan adalah apakah kasus Anda termasuk yang tepat atau tidak.
Tiga variabel berikut membantu Anda memutuskan.
Volume per request cycle. Berapa banyak email yang dikirim dalam satu request pengguna? Kalau di bawah 5 email per request dan tidak ada loop, synchronous masih sangat acceptable. Bottleneck queue terasa nyata ketika Anda mulai bicara 10+ email per request cycle, atau ketika ada batch processing yang memang secara teknis mengirim banyak email sekaligus.
SLA atau ekspektasi response time. Apakah pengguna Anda menunggu email itu sebagai bagian dari transaksi utama? Email OTP adalah contoh klasik yang tidak boleh asynchronous. Pengguna sedang login, mereka tunggu kode. Kalau email OTP dikirim via queue dan queue worker sedang backlog, pengalaman pengguna hancur. Email tipe ini harus synchronous, apa pun alasannya.
Tipe email. Email transaksional yang langsung terkait dengan aksi pengguna, OTP, verifikasi, konfirmasi payment, biasanya harus synchronous. Email yang informasional, newsletter, report berkala, notifikasi update, sangat cocok untuk queue. Perbedaannya: apakah keterlambatan 30 detik sampai 5 menit masih bisa diterima oleh pengguna untuk email ini?
Kalau tiga variabel ini menghasilkan jawaban “volume rendah, email kritis, dan delay tidak bisa diterima”, Mail::send sudah cukup untuk saat ini.
Kapan Queue Email Bukan Overkill tapi Kebutuhan?
Queue email mulai memberikan manfaat nyata di tiga situasi.
Pertama: batch email processing yang volume-nya di atas threshold. Kalau aplikasi Anda mengirim email ke ratusan atau ribuan penerima dalam satu proses, newsletter massal, report bulk, notifikasi event, synchronous jelas tidak realistis. Setiap SMTP connection makan waktu. Queue memindahkan proses ini ke background worker yang berjalan terpisah dari request pengguna.
Kedua: aplikasi yang punya SLA response time yang ketat. Bayangkan aplikasi e-commerce yang setiap endpoint harus selesai dalam 200ms. Menambahkan 2 detik untuk satu email di endpoint checkout akan merusak SLA. Email order confirmation tidak harus sampai ke pengguna dalam 200ms, 2 menit kemudian juga tidak apa-apa. Yang penting: endpoint checkout selesai cepat dan pengguna dapat konfirmasi di layar mereka. Queue memungkinkan ini.
Ketiga: email yang toleran terhadap delay dan kegagalan transient. Email newsletter, report harian, atau notifikasi yang tidak urgent, ini kasus sempurna untuk queue. Kalau queue worker restart atau ada temporary SMTP failure, Laravel secara default akan retry job yang gagal. Anda tidak kehilangan email, dan pengguna tidak perlu tahu ada proses background yang sedang berjalan.
Angka Nyata yang Perlu Anda Pahami Sebelum Switch?
Berikut angka yang sering muncul di laporan developer yang mengalami masalah email performance secara langsung.
SMTP connection time untuk satu email melalui SMTP eksternal adalah 1-2 detik. Ini sudah termasuk DNS lookup, TCP handshake, TLS negotiation, dan SMTP command exchange. Local SMTP server biasanya lebih cepat, kecuali kalau server tersebut juga punya keterbatasan resource.
Kalau aplikasi Anda mengirim 10 email secara synchronous dalam satu request, tambahan waktu adalah 10-20 detik. Untuk 50 email: 50-100 detik. Ini bukan kode yang salah. Ini physics dari SMTP itu sendiri.
Angka-angka ini membantu Anda punya baseline. Kalau Anda tahu aplikasi Anda mengirim 3 email per checkout dan SLA endpoint checkout adalah 500ms, Anda bisa hitung sendiri. Tiga email dikali 1,5 detik sama dengan 4,5 detik tambahan. Queue bukan pilihan lagi di titik ini, ini kebutuhan.
Harus Pindah ke Queue Atau Belum?
Gunakan daftar ini untuk evaluasi cepat.
Anda perlu queue ketika:
- Volume email per request cycle sudah lebih dari 5 dan tidak bisa direduksi
- Endpoint yang kirim email punya SLA di bawah 1 detik
- Email yang dikirim bukan bagian kritis dari transaksi yang sedang berjalan
- Aplikasi mengirim email dalam batch ke banyak penerima sekaligus
Anda belum perlu queue ketika:
- Rata-rata 1-3 email per request
- Email termasuk tipe kritis: OTP, verifikasi, konfirmasi payment
- Response time aplikasi tidak jadi masalah untuk email yang dikirim
- Anda belum punya infrastruktur queue worker yang running
Kalau aplikasi Anda termasuk kategori kedua tapi volume email mulai naik, pantau terus metrik ini. Threshold-nya bukan angka absolut, melainkan ketika Anda mulai merasa response time pengguna mulai terganggu, atau ketika queue backlog mulai menumpuk di jam-jam sibuk.
Setup Queue Email di Laravel: Langkah yang Benar?
Setelah Anda putuskan perlu queue, berikut langkah yang benar di Laravel.
Pastikan queue driver sudah dikonfigurasi. Untuk production, gunakan Redis atau database sebagai queue backend. Untuk development, queue driver sync memudahkan debugging tanpa kompleksitas worker.
MAIL_MAILER=smtp
QUEUE_CONNECTION=redis
Setelah itu, buat job untuk email Anda.
use App\\Jobs\\SendWelcomeEmail;
use App\\Mail\\WelcomeMail;
use Illuminate\\Support\\Facades\\Mail;
class SendWelcomeEmail extends Job
{
public function handle()
{
Mail::to($this->user->email)->send(new WelcomeMail($this->user));
}
}
Panggil job dari controller.
SendWelcomeEmail::dispatch($user);
Satu hal yang sering terlewat: queue job tetap memanggil Mail::send. Yang berbeda hanya execution context, async via worker, bukan synchronous dalam request. Ini penting karena banyak developer mengira queue menggantikan Mail::send. Tidak. Queue hanya memindahkan kapan Mail::send dijalankan.
Yang Perlu Dipantau Setelah Queue Email Berjalan?
Setelah queue email aktif, ada tiga metrik yang perlu Anda watch.
Queue latency. Berapa lama antara job di-dispatch dan job selesai diproses. Kalau latency naik terus, artinya queue worker Anda kurang untuk volume email yang masuk.
Email bounce rate. Bounce yang tidak ditangani membuat email berikutnya dari domain yang sama mulai ditandai spam. Rate di atas 5% sudah perlu perhatian.
Retry rate. Kalau banyak job yang retry, cek apakah SMTP provider Anda stable. KIRIM.EMAIL Dev menyediakan monitoring dashboard untuk email transaksional termasuk queue status, sehingga Anda bisa dapat alert sebelum masalah ini mempengaruhi pengguna.
Queue bukan finish line. Ini bagian dari infrastruktur yang perlu dimonitor, sama seperti SMTP itu sendiri.
Pertanyaan yang Sering Diajukan
Kenapa email Laravel saya lambat padahal SMTP provider sudah bagus?
Bottleneck biasanya bukan di provider SMTP-nya. Kalau email dikirim synchronous dengan Mail::send, setiap panggilan SMTP memakan 1-2 detik. Ini terjadi di sisi aplikasi Anda, bukan di sisi provider. Solusinya: evaluasi apakah email tersebut perlu dikirim sekarang atau bisa dipindahkan ke queue.
Berapa volume email per request yang masih aman untuk Mail::send?
Untuk email tipe non-kritis, newsletter atau notifikasi, di bawah 5 email per request masih acceptable. Untuk email tipe kritis, OTP, verifikasi, payment confirmation, sebaiknya tetap synchronous apa pun volumenya karena delay 30 detik saja sudah merusak pengalaman pengguna.
Kapan queue email menjadi overkill?
Queue email overkill ketika volume email Anda rendah dan tidak ada SLA yang ketat. Menambah queue worker, monitoring, dan kompleksitas infrastruktur untuk 10 email per hari tidak sebanding dengan manfaatnya. Evaluasi lagi apakah Anda benar-benar butuh queue, atau hanya mengikuti tutorial tanpa mengukur apakah masalah Anda memang ada.
Apakah queue worker harus selalu running?
Ya. Kalau queue worker berhenti, job akan tetap tersimpan di backend, Redis atau database, sampai worker jalan lagi. Laravel secara default retry job yang gagal. Tapi kalau worker tidak pernah jalan, email tidak pernah terkirim.
Apa bedanya queue untuk email dan cron job untuk email?
Queue dirancang untuk email yang perlu dikirim segera setelah suatu event terjadi, new user registration, order confirmation. Cron job untuk email terjadwal, report harian, newsletter mingguan. Keduanya bisa mengirim email, tapi use case-nya berbeda.
