ShouldBeUnique vs WithoutOverlapping di Laravel 12

Pernah nggak sih kamu bikin aplikasi Laravel yang butuh proses background, misal hitung tagihan user atau update data secara otomatis? Nah, Laravel punya fitur queue yang super powerful buat hal kayak gini. Tapi, kadang muncul masalah: gimana caranya biar job yang sama nggak jalan barengan dan bikin data kacau?

Laravel 12 membawa beberapa peningkatan di sistem queue, termasuk perbaikan pada ShouldBeUnique dan WithoutOverlapping. Artikel ini sudah disesuaikan dengan fitur dan best practice terbaru Laravel 12.

Di artikel ini, kita bakal bahas dua solusi keren dari Laravel: ShouldBeUnique dan WithoutOverlapping. Keduanya mirip, tapi punya perbedaan penting yang wajib kamu tahu sebelum dipakai di project.

Di dunia nyata: Job Tagihan User yang Sering Bentrok

Bayangin kamu punya fitur yang otomatis hitung berapa tagihan user setiap kali:

User update metode pembayaran
User kena charge baru
Billing cycle user sudah sampai

Setiap event di atas bakal langsung dispatch job ke queue buat hitung total tagihan. Masalahnya, kadang event itu terjadi bersamaan, dan akhirnya ada beberapa job yang jalan barengan. Ini bisa bikin data tagihan jadi nggak akurat karena ada race condition—siapa yang update duluan?

Jadi, gimana caranya biar cuma satu job yang proses tagihan user di waktu yang sama?

ShouldBeUnique: Mencegah Job Duplikat Masuk Queue

Laravel punya interface ShouldBeUnique yang bisa kamu implement di job class. Fungsinya simpel: mencegah job duplikat masuk ke queue. Kalau ada job yang sama sudah ada di queue atau sedang diproses, job baru nggak akan masuk.

Catatan Laravel 12: Di Laravel 12, ShouldBeUnique sudah lebih stabil dan mendukung pengaturan waktu kadaluarsa (uniqueFor) secara lebih fleksibel. Kamu bisa menambah properti public int $uniqueFor = 300; di job untuk mengatur berapa lama job dianggap unik (dalam detik).

Contoh Implementasi

use Illuminate\Contracts\Queue\ShouldBeUnique;

class UpdateUserStatement implements ShouldBeUnique
{
    public int $uniqueFor = 300; // job dianggap unik selama 5 menit

    public function __construct(public User $user) {}

    public function handle(): void
    {
        // ...proses update tagihan user...
    }
}

Penjelasan:

Kalau job dengan parameter yang sama sudah ada di queue atau sedang running, job baru akan diabaikan.
Cocok buat kasus di mana kamu nggak mau ada job duplikat sama sekali.

Kelebihan:

Simple, nggak perlu mikir lock manual
Aman dari job duplikat
Di Laravel 12, bisa atur waktu kadaluarsa job unik

Kekurangan:

Kadang kamu tetap butuh job baru masuk, tapi jangan diproses barengan
Kalau butuh job dengan parameter berbeda, harus atur uniqueId

Referensi:

Laravel Docs: Unique Jobs (Laravel 12)

WithoutOverlapping: Mencegah Job Jalan Barengan

Nah, kalau kamu tetap mau job duplikat masuk ke queue, tapi nggak mau diproses bersamaan, pakai middleware WithoutOverlapping. Middleware ini pakai atomic lock, jadi job dengan key yang sama nggak akan diproses barengan.

Catatan Laravel 12: Di Laravel 12, middleware ini mendukung pengaturan waktu lock dan retry lebih baik. Kamu bisa pakai releaseAfter dan juga menambah maxAttempts agar job tidak gagal terlalu cepat.

Contoh Implementasi

use Illuminate\Queue\Middleware\WithoutOverlapping;

class UpdateUserStatement implements ShouldQueue
{
    public function __construct(public User $user) {}

    public function handle(): void
    {
        // ...proses update tagihan user...
    }

    public function middleware(): array
    {
        // Hanya satu job dengan user id yang sama boleh running
        return [
            (new WithoutOverlapping($this->user->id))
                ->releaseAfter(5) // retry setelah 5 detik
                ->expireAfter(60) // lock kadaluarsa setelah 1 menit
        ];
    }
}

Penjelasan:

Job dengan key (misal user id) yang sama nggak akan running barengan
Kalau ada job overlap, job akan di-release dan dicoba lagi setelah waktu tertentu
Cocok buat resource yang nggak boleh diubah barengan

Kelebihan:

Flexible, job tetap bisa masuk queue
Aman dari race condition
Bisa atur waktu release, expire, dan retry

Kekurangan:

Kalau retry terlalu sering, job bisa gagal permanen
Perlu atur key dengan benar

Referensi:

Laravel Docs: Preventing Job Overlaps (Laravel 12)

Analogi Sederhana

ShouldBeUnique itu kayak satpam di pintu masuk: kalau ada tamu yang sama sudah di dalam, tamu baru nggak boleh masuk.
WithoutOverlapping itu kayak satpam di ruang kerja: tamu boleh masuk antrian, tapi cuma satu yang boleh kerja di ruangan pada satu waktu.

Kapan Pakai yang Mana?

ShouldBeUnique: Kalau kamu nggak mau ada job duplikat sama sekali di queue. Cocok buat proses yang harus benar-benar unik.
WithoutOverlapping: Kalau job boleh masuk queue, tapi nggak boleh running barengan. Cocok buat proses yang bisa diulang, tapi harus satu-satu.

Tips Praktis untuk Pemula

Selalu cek kebutuhan aplikasi sebelum pilih solusi
Untuk job yang update data sensitif (misal saldo, tagihan), lebih aman pakai WithoutOverlapping
Jangan lupa atur key dengan benar (misal pakai user id atau resource id)
Test dulu di local sebelum deploy ke production
Cek dokumentasi resmi Laravel untuk update terbaru

Contoh Struktur File Job di Laravel

app/
  Jobs/
    UpdateUserStatement.php

Troubleshooting Error yang Sering Muncul

Job nggak masuk queue: Cek implementasi ShouldBeUnique, pastikan uniqueId dan uniqueFor sudah sesuai kebutuhan
Job gagal terus di retry: Cek middleware WithoutOverlapping, atur waktu release, expire, dan maxAttempts
Job tetap overlap: Pastikan key yang dipakai benar-benar unik untuk resource

Sumber Belajar dan Dokumentasi

Ringkasan dan Langkah Selanjutnya

Sekarang kamu sudah tahu perbedaan ShouldBeUnique dan WithoutOverlapping di Laravel 10. Pilih yang paling sesuai dengan kebutuhan aplikasi kamu, dan jangan ragu buat eksperimen di local dulu. Semangat belajar Laravel, dan jangan takut coba-coba fitur baru!