Tujuan Pembelajaran

Memahami kenapa notifikasi harus dikirim via queue, bukan langsung
Mampu mengimplementasikan retry dengan exponential backoff
Mampu menangani failed notifications dengan dead letter queue

Analogi

Diagram


      Notification Queue = Antrean di Bank:

Tanpa queue (sync):
Karyawan layani nasabah 1 → selesai → nasabah 2
Kalau nasabah 1 lama → nasabah 2-100 menunggu (request timeout)

Dengan queue (async):
Nasabah ambil nomor antrean → duduk tunggu
Karyawan panggil satu per satu → proses → selesai
Kalau nasabah 1 bermasalah → lanjut nasabah 2 (tidak blocking)

Dead Letter Queue:
Nasabah yang sudah dipanggil 3x tidak merespon → masuk daftar khusus untuk ditindaklanjuti manual.

Notification queue seperti antrean bank — async, tidak blocking request utama. Dead letter = kasus khusus yang butuh penanganan manual.

Penjelasan Konsep

Notifikasi harus dikirim secara asinkron — jangan mem-blocking response ke user hanya karena email belum terkirim.

Kenapa queue: (1) Tidak blocking — request POST /api/order langsung return, notifikasi diproses di background. (2) Retry otomatis — kalau email provider down, queue akan retry. (3) Rate limiting — queue mengatur kecepatan pengiriman (jangan spam provider). (4) Durability — kalau server crash, notifikasi di queue tidak hilang.

Queue implementation: (1) Simple — database table notification_queue (id, type, payload, status, retry_count, next_retry_at). Worker process (cron job atau loop) ambil pending notifications, kirim, update status. (2) Advanced — Redis + BullMQ / RabbitMQ untuk high throughput.

Retry strategy: (1) Exponential backoff — retry 1: 1 menit, retry 2: 5 menit, retry 3: 25 menit, retry 4: 2 jam. (2) Max retries — setelah 5x gagal, jangan retry lagi (mengurangi beban provider). (3) Smart retry — jangan retry hard bounce (email invalid), retry untuk soft bounce (temporary failure).

Dead Letter Queue: Notifikasi yang gagal setelah max retries. Dipindahkan ke DLQ untuk investigasi manual. Tim bisa melihat kenapa gagal (error message) dan memutuskan: resend? abaikan? perbaiki data?

Inti yang Perlu Dipahami

Bagian ini berfokus pada memahami kenapa notifikasi harus dikirim via queue, bukan langsung., mampu mengimplementasikan retry dengan exponential backoff., dan mampu menangani failed notifications dengan dead letter queue. Jangan terburu-buru menghafal istilahnya. Lebih penting untuk memahami peran setiap konsep dan kapan konsep itu muncul dalam pekerjaan web development.

Saat membaca Queue & Retry, gunakan tujuan belajar sebagai penanda arah. Kalau kamu sudah bisa menjelaskan tujuan itu dengan kata-katamu sendiri, berarti fondasinya mulai terbentuk.

Cara Membayangkannya

Notification queue seperti antrean bank — async, tidak blocking request utama. Dead letter = kasus khusus yang butuh penanganan manual. Analogi ini dipakai supaya konsep teknis tidak terasa melayang. Hubungkan setiap istilah dengan perannya: siapa yang meminta, siapa yang memproses, data apa yang berpindah, dan hasil apa yang diharapkan.

Kalau analoginya sudah terasa masuk akal, barulah lihat istilah teknisnya. Cara ini membuat materi lebih mudah dipahami daripada langsung menghafal definisi.

Saat Melihat Contoh Kode

Contoh kode pada chapter ini memakai bahasa typescript. Bacalah contoh kode sebagai ilustrasi alur, bukan sebagai bagian yang harus langsung dihafal.

Perhatikan nama fungsi, urutan langkah, dan data yang berpindah. Biasanya tiga hal itu sudah cukup untuk memahami hubungan antara teori dan praktik.

Konteks dalam Perjalanan Belajar

Setiap konsep di platform ini dipilih karena dipakai di industri. Fokus pada pemahaman, bukan hafalan.

Kamu sudah di bagian lanjutan. Mulai pikirkan bagaimana konsep ini dipakai di dunia kerja — bukan hanya untuk belajar, tapi untuk membangun produk nyata.

Gunakan pertanyaan reflektif dan prompt AI di akhir chapter sebagai latihan aktif. Membaca saja tidak cukup — kamu perlu menjelaskan ulang dengan kata-katamu sendiri.

Contoh Kode

typescript

// Simple notification queue worker
async function processNotificationQueue() {
  const pending = await db.query.notificationQueue.findMany({
    where: and(
      eq(notificationQueue.status, 'pending'),
      lte(notificationQueue.nextRetryAt, new Date()),
      lt(notificationQueue.retryCount, 5),
    ),
    limit: 50,
  });
  
  for (const notification of pending) {
    try {
      await sendNotification(notification);
      await db.update(notificationQueue)
        .set({ status: 'sent', sentAt: new Date() })
        .where(eq(notificationQueue.id, notification.id));
    } catch (error) {
      const nextRetry = new Date(Date.now() + Math.pow(2, notification.retryCount) * 60_000);
      await db.update(notificationQueue).set({
        retryCount: notification.retryCount + 1,
        nextRetryAt: nextRetry,
        status: notification.retryCount >= 4 ? 'dead_letter' : 'pending',
        lastError: error.message,
      }).where(eq(notificationQueue.id, notification.id));
    }
  }
}

// Run every 30 seconds
setInterval(processNotificationQueue, 30_000);

Prompt AI

Implementasi notification queue dengan exponential backoff retry. Gunakan database table sebagai queue. Implementasi worker yang berjalan setiap 30 detik, dan dead letter handling.

Pertanyaan Reflektif

Apa yang terjadi kalau email provider di aplikasi-mu down? Apakah notifikasi gagal dan hilang selamanya? Atau masuk queue untuk retry nanti?