Redis lock untuk worker queue dipakai ketika beberapa worker bisa mengambil atau mengeksekusi pekerjaan yang sama, lalu menyebabkan duplicate execution. Masalah ini sering muncul pada job yang menyentuh resource bersama: mengirim invoice, sinkronisasi data eksternal, settlement pembayaran, atau pembaruan status yang tidak boleh diproses paralel.

Namun lock bukan solusi universal. Jika salah memilih TTL, tidak punya mekanisme renewal, atau melepas lock tanpa verifikasi pemilik, Anda justru bisa mendapat efek samping: job ganda, lock tertinggal setelah worker crash, retry yang memperparah konflik, sampai deadlock semu ketika semua worker terus gagal mengambil lock dan sistem tampak macet. Kunci desain yang aman adalah: lock dengan TTL, owner token unik, perpanjangan lock saat job masih berjalan, safe release, backoff saat gagal, serta observability yang cukup untuk recovery operasional.

Kapan Redis lock diperlukan, dan kapan idempotency saja lebih tepat

Tidak semua queue membutuhkan lock. Sebelum menambah kompleksitas, bedakan dulu dua kebutuhan berikut.

Saat lock memang diperlukan

  • Akses eksklusif ke resource bersama, misalnya satu account, satu invoice, satu order, atau satu file hanya boleh diproses satu worker pada satu waktu.
  • Operasi tidak aman jika paralel, misalnya dua worker bisa menghitung saldo dari state lama lalu menimpa hasil satu sama lain.
  • Sistem eksternal tidak mendukung idempotency dengan baik, contohnya API pihak ketiga memproses request duplikat sebagai transaksi baru.
  • Queue bisa mengantarkan ulang job karena timeout, crash, atau retry, dan Anda butuh pagar tambahan agar dua eksekusi tidak berjalan bersamaan.

Saat idempotency lebih tepat

  • Efek akhir boleh diulang tanpa mengubah hasil, misalnya menandai record ke status yang sama atau mengisi cache.
  • Anda bisa menyimpan deduplication key di database dengan unique constraint atau tabel jejak eksekusi.
  • Operasi lebih aman diselesaikan di layer data daripada bergantung pada lock sementara di Redis.

Contoh umum: untuk pembuatan invoice, sering kali lebih aman memakai idempotency key + unique constraint agar invoice tidak pernah tercatat ganda, lalu lock dipakai hanya untuk mencegah dua worker mengerjakan sumber yang sama secara bersamaan. Dengan kata lain, lock mencegah konkurensi saat ini, idempotency melindungi hasil akhir. Pada sistem penting, keduanya sering dipakai bersama.

Masalah nyata pada worker queue yang sering terjadi

1. Duplicate execution

Job bisa jalan ganda karena lebih dari satu worker menerima job yang sama, visibility timeout queue habis terlalu cepat, ack terlambat, atau worker pertama masih jalan ketika job diantarkan ulang. Tanpa lock atau idempotency, efeknya bisa fatal: email terkirim dua kali, pembayaran tercatat ganda, stok berkurang dua kali.

2. Lock timeout terlalu pendek

Jika TTL lock lebih pendek dari durasi kerja nyata, lock bisa habis saat worker masih memproses. Worker lain lalu berhasil mengambil lock baru dan menjalankan job yang sama secara paralel. Ini salah satu sumber duplicate execution paling sering.

TTL lock harus lebih panjang dari pekerjaan normal, atau lock harus bisa diperpanjang secara aman selama worker masih sehat.

3. Lock timeout terlalu panjang

TTL yang terlalu panjang memang mengurangi risiko lock kedaluwarsa saat job masih berjalan, tetapi memperlambat pemulihan jika worker crash. Resource tampak "terkunci" lama padahal pemilik lock sudah mati. Ini sering terasa seperti deadlock, padahal sebenarnya lock hanya belum kedaluwarsa.

4. Worker crash di tengah proses

Inilah alasan lock di Redis hampir selalu perlu TTL. Jika worker mati setelah mengambil lock dan sebelum melepaskannya, sistem harus bisa pulih otomatis setelah TTL habis. Tanpa TTL, lock bisa bocor dan memblokir pekerjaan berikutnya tanpa batas.

5. Deadlock semu

Pada worker queue, deadlock klasik tidak selalu terjadi seperti pada database yang saling menunggu dua resource. Yang lebih sering adalah deadlock semu: banyak worker berebut lock yang sama, gagal, lalu retry serempak tanpa jeda. Akibatnya throughput turun, antrean memanjang, dan sistem tampak macet walau tidak ada deadlock sejati.

6. Clock drift dan asumsi waktu yang salah

Jangan membuat keputusan kepemilikan lock berdasarkan jam lokal aplikasi, karena clock antar mesin bisa bergeser. Dalam desain sederhana berbasis Redis, lebih aman memperlakukan TTL sebagai kontrak yang ditegakkan Redis, bukan menghitung sendiri "apakah lock ini seharusnya sudah habis" dari waktu lokal worker.

7. Efek retry yang memperparah konflik

Retry memang membantu reliabilitas, tetapi jika setiap kegagalan lock langsung diretry tanpa backoff dan jitter, semua worker akan terus menabrak key yang sama. Ini meningkatkan beban Redis dan memperburuk kontensi.

Desain Redis lock yang aman untuk worker queue

Untuk kasus satu resource dikunci oleh satu worker, pola minimal yang aman biasanya terdiri dari:

  1. Lock key spesifik resource, misalnya lock:order:123.
  2. Owner token unik per eksekusi job, bukan hanya ID worker. Misalnya UUID acak.
  3. Acquire atomik hanya jika key belum ada, dengan TTL.
  4. Renewal jika job berjalan lebih lama dari perkiraan.
  5. Safe release hanya jika token pada Redis masih sama dengan token milik worker saat ini.
  6. Backoff + jitter bila lock gagal diperoleh.
  7. Idempotency untuk melindungi efek akhir dari eksekusi ulang.

Mengapa owner token wajib

Tanpa owner token, worker A bisa tidak sengaja menghapus lock milik worker B. Skenario klasiknya:

  1. Worker A mengambil lock dengan TTL 30 detik.
  2. Job A berjalan lambat, TTL habis.
  3. Worker B mengambil lock baru untuk resource yang sama.
  4. Worker A selesai dan menjalankan DEL lock:key.
  5. Lock milik B ikut terhapus, sehingga worker lain bisa masuk lagi.

Karena itu, pelepasan lock harus memeriksa bahwa nilai key masih sama dengan token milik worker yang akan melepaskan lock.

Pseudocode acquire, renew, dan safe release

function processJob(job):
    resourceKey = "lock:order:" + job.orderId
    ownerToken = randomUUID()
    lockTtlMs = 60000

    acquired = redis.SET(resourceKey, ownerToken, NX=true, PX=lockTtlMs)
    if not acquired:
        rescheduleWithBackoff(job)
        return

    startRenewLoop(resourceKey, ownerToken, everyMs=20000, ttlMs=lockTtlMs)

    try:
        if alreadyProcessed(job.idempotencyKey):
            return

        doWork(job)
        markProcessed(job.idempotencyKey)
    finally:
        stopRenewLoop()
        safeRelease(resourceKey, ownerToken)

function safeRelease(resourceKey, ownerToken):
    script = """
    if redis.call('GET', KEYS[1]) == ARGV[1] then
        return redis.call('DEL', KEYS[1])
    else
        return 0
    end
    """
    redis.EVAL(script, keys=[resourceKey], args=[ownerToken])

function renewLock(resourceKey, ownerToken, ttlMs):
    script = """
    if redis.call('GET', KEYS[1]) == ARGV[1] then
        return redis.call('PEXPIRE', KEYS[1], ARGV[2])
    else
        return 0
    end
    """
    return redis.EVAL(script, keys=[resourceKey], args=[ownerToken, ttlMs])

Poin penting dari contoh di atas:

  • SET ... NX PX memastikan lock dibuat hanya jika belum ada, sekaligus memberi TTL.
  • Renewal dilakukan berkala sebelum TTL habis, tetapi hanya jika token masih cocok.
  • Safe release juga memverifikasi token agar tidak menghapus lock milik eksekusi lain.
  • Idempotency check tetap ada karena lock bukan jaminan absolut terhadap semua kegagalan distribusi.

Menentukan TTL yang masuk akal

Tidak ada angka universal, tetapi beberapa prinsip praktis bisa dipakai:

  • Pilih TTL yang lebih besar dari durasi normal job, bukan durasi ideal di kondisi terbaik.
  • Jika durasi job bervariasi jauh, jangan mengandalkan TTL statis saja; gunakan renewal.
  • Interval renewal sebaiknya cukup cepat sehingga Anda punya beberapa kesempatan memperpanjang lock sebelum habis.
  • Hindari TTL sangat panjang hanya untuk "aman" karena recovery setelah crash jadi lambat.

Aturan praktis: TTL awal cukup untuk menutup durasi mayoritas job, lalu renewal berjalan periodik. Jika renewal gagal, worker harus menganggap ia kehilangan kepemilikan lock dan berhenti melanjutkan operasi yang berisiko.

Apa yang dilakukan worker jika renewal gagal

Jika perpanjangan lock gagal, artinya salah satu dari dua hal mungkin terjadi: lock sudah kedaluwarsa lalu diambil eksekusi lain, atau koneksi ke Redis bermasalah. Dalam kondisi ini, pilihan aman adalah:

  • Hentikan pemrosesan jika memungkinkan.
  • Jangan menulis hasil akhir yang bisa bentrok.
  • Tandai job sebagai gagal/abort agar bisa dianalisis atau dicoba ulang dengan aman.

Ini penting untuk mencegah dua worker menganggap mereka sama-sama sah memproses resource yang sama.

Backoff, retry, dan menghindari deadlock semu

Gagal mengambil lock bukan berarti sistem rusak. Itu bisa berarti ada worker lain yang sedang memproses resource tersebut. Yang berbahaya adalah cara Anda merespons kegagalan itu.

Gunakan backoff dengan jitter

Jika semua worker retry pada interval tetap, mereka akan kembali bertabrakan pada saat yang hampir sama. Tambahkan jitter acak agar distribusi percobaan lebih merata.

function rescheduleWithBackoff(job):
    attempt = job.attempt
    baseDelayMs = min(30000, 500 * (2 ^ attempt))
    jitterMs = random(0, 1000)
    delay(job, baseDelayMs + jitterMs)

Untuk job yang hanya terkunci sementara, strategi ini biasanya lebih sehat daripada loop sibuk yang terus mencoba lock.

Bedakan retry karena lock contention dan retry karena error bisnis

Jangan perlakukan semuanya sama. Retry karena lock sedang dipakai worker lain biasanya tidak perlu meningkatkan tingkat keparahan alert. Sebaliknya, retry karena kegagalan logika bisnis atau kegagalan sistem eksternal mungkin butuh penanganan berbeda.

Hindari busy waiting

Worker yang terus polling Redis tanpa jeda dapat menghabiskan CPU dan koneksi, memperburuk latensi sistem lain. Pada queue, lebih baik job ditunda atau dikembalikan ke antrean dengan delay terkontrol.

Observability dan recovery operasional

Lock yang baik bukan hanya soal algoritme, tetapi juga soal bisa diamati saat keadaan buruk terjadi.

Metrik yang sebaiknya dicatat

  • Jumlah lock acquire sukses/gagal.
  • Waktu tunggu sampai lock didapat.
  • Jumlah renewal sukses/gagal.
  • Jumlah safe release gagal karena token tidak cocok.
  • Jumlah job yang di-abort karena kehilangan lock.
  • Jumlah retry akibat contention dibanding retry akibat error lain.

Log yang berguna saat insiden

Minimal log berikut sebaiknya ada:

  • job ID
  • resource key yang dikunci
  • owner token
  • TTL awal
  • waktu acquire
  • hasil renewal
  • alasan retry atau abort

Tanpa ini, sulit membedakan apakah job macet karena lock benar-benar tertahan, worker crash, atau bug pada logika release.

Recovery operasional

Saat ada indikasi lock bermasalah, jangan langsung menghapus key secara manual tanpa verifikasi. Langkah yang lebih aman:

  1. Pastikan tidak ada worker aktif yang masih memegang lock itu.
  2. Cek umur lock, pola renewal, dan log job terkait.
  3. Jika perlu penghapusan manual, dokumentasikan resource, alasan, dan waktu tindakan.
  4. Setelah insiden, evaluasi apakah TTL terlalu panjang, renewal tidak stabil, atau retry terlalu agresif.

Penghapusan lock manual adalah tindakan operasional terakhir, bukan mekanisme normal. Jika terlalu sering diperlukan, desain lock Anda perlu diperbaiki.

Keterbatasan Redis lock yang perlu dipahami

Lock bukan pengganti integritas data

Jika konsekuensi duplikasi sangat mahal, tetap simpan perlindungan di layer data: unique constraint, status transisi atomik, atau idempotency key yang persisten. Redis lock membantu mengurangi konflik saat runtime, tetapi tidak seharusnya menjadi satu-satunya pagar.

Gangguan jaringan bisa membuat keadaan ambigu

Worker bisa sukses memproses sebagian pekerjaan tetapi gagal memastikan status lock atau hasil akhir karena koneksi bermasalah. Karena itu, desain akhir tetap harus tahan terhadap eksekusi ulang sebagian.

Clock drift membuat logika berbasis waktu lokal rawan salah

Jangan menghitung validitas lock dari jam mesin aplikasi. Serahkan TTL kepada Redis dan gunakan verifikasi token pada setiap operasi sensitif terkait lock.

Kapan memilih database lock atau fitur queue bawaan

Pilih Redis lock jika

  • Anda butuh lock cepat dengan overhead rendah.
  • Resource yang dikunci sederhana dan TTL sementara sudah cukup.
  • Anda siap menambahkan renewal, observability, dan idempotency.

Pilih database lock jika

  • Konsistensi data lebih penting daripada latensi rendah.
  • Operasi inti sudah berada dalam transaksi database.
  • Anda perlu koordinasi yang sangat dekat dengan row yang sedang diubah, misalnya row-level locking atau advisory lock.

Keuntungan pendekatan database adalah lock dan perubahan data bisa lebih dekat secara transaksi. Kekurangannya, kontensi bisa membebani database utama.

Pilih fitur queue bawaan jika

  • Sistem antrean Anda sudah mendukung deduplikasi, visibility timeout yang tepat, partitioning, atau single consumer semantics untuk kasus tertentu.
  • Masalah Anda sebenarnya bukan lock resource, tetapi delivery semantics queue yang perlu dikonfigurasi dengan benar.

Sering kali akar masalah bukan tidak adanya Redis lock, melainkan visibility timeout queue terlalu pendek atau job tidak idempoten.

Anti-pattern umum

  • Melepas lock dengan DEL biasa tanpa memeriksa owner token.
  • TTL statis tanpa renewal untuk job yang durasinya tidak bisa diprediksi.
  • Mengandalkan lock saja tanpa idempotency pada operasi penting.
  • Retry langsung dan serempak tanpa backoff atau jitter.
  • Satu lock global untuk semua job, padahal yang dibutuhkan lock per resource. Ini membunuh paralelisme.
  • TTL terlalu panjang hingga recovery setelah crash terasa seperti deadlock.
  • Menggunakan waktu lokal worker untuk memutuskan lock sudah kedaluwarsa.
  • Tidak ada metrik dan log, sehingga insiden sulit ditelusuri.

Checklist implementasi Redis lock untuk worker queue

  • Gunakan key lock per resource, bukan satu lock global.
  • Simpan owner token unik sebagai value lock.
  • Acquire lock secara atomik dengan TTL.
  • Tentukan TTL awal berdasarkan durasi kerja nyata, bukan asumsi optimistis.
  • Tambahkan renewal periodik untuk job yang bisa berjalan lama.
  • Lakukan safe release dengan verifikasi token.
  • Jika renewal gagal, anggap lock hilang dan hentikan operasi yang berisiko.
  • Terapkan idempotency key atau perlindungan di database untuk hasil akhir.
  • Gunakan retry dengan backoff dan jitter saat lock tidak tersedia.
  • Bedakan metrik contention, error bisnis, dan error infrastruktur.
  • Siapkan prosedur recovery operasional untuk lock tersangkut.
  • Uji skenario crash, TTL habis, renewal gagal, dan duplicate delivery sebelum produksi.

Penutup

Redis lock untuk worker queue efektif untuk mencegah job diproses ganda saat ada banyak worker, tetapi hanya jika desainnya aman. Minimum yang sebaiknya ada adalah TTL, owner token, renewal, safe release, backoff, dan observability. Di atas itu, idempotency tetap penting karena lock tidak bisa menjamin semua jenis kegagalan pada sistem terdistribusi.

Jika kebutuhan Anda adalah eksklusivitas sementara per resource, Redis lock cocok dan praktis. Jika yang Anda butuhkan adalah integritas hasil akhir, pertimbangkan unique constraint, transaksi database, atau fitur queue bawaan terlebih dahulu. Dalam banyak sistem produksi, solusi terbaik bukan memilih salah satu, melainkan menggabungkan lock untuk koordinasi runtime dan idempotency untuk keselamatan data.