Queue Worker untuk Browser Konsol: Cache, Lock, dan Retry yang Aman

Queue worker untuk browser konsol perlu dirancang berbeda dari klien web biasa. Masalah utamanya bukan sekadar latensi, tetapi kombinasi koneksi lambat, resume jaringan yang buruk, request yang terputus di tengah jalan, dan browser yang dapat mengulangi request tanpa pola yang bersih. Jika backend mengasumsikan setiap request hanya datang sekali, hasilnya sering berupa job ganda, cache stale, retry yang menumpuk, dan lock yang tidak pernah benar-benar dilepas.

Pendekatan yang lebih aman adalah memisahkan penerimaan request dari eksekusi kerja berat: API menerima request, memberi acknowledgement cepat, lalu mendorong pekerjaan ke queue untuk diproses worker. Namun queue saja tidak cukup. Agar sistem tahan terhadap perilaku klien “aneh”, Anda juga perlu idempotency key, visibility timeout, distributed lock dengan TTL, strategi invalidasi cache, backoff retry yang terkendali, dead-letter queue, dan observability yang bisa dipakai saat insiden.

Konteks browser console di sini penting sebagai contoh klien dengan perilaku jaringan yang tidak rapi. Solusi yang dibahas tetap relevan untuk mobile app, embedded browser, smart TV, dan integrasi pihak ketiga yang sering mengulang request secara agresif.

Masalah nyata pada browser konsol

Pada klien desktop modern, retry dan koneksi ulang biasanya lebih dapat diprediksi. Di browser console, Anda bisa menemui pola seperti:

Request POST dikirim ulang karena browser tidak yakin respons sebelumnya diterima.
Koneksi putus setelah backend menerima request, tetapi sebelum klien menerima respons.
Halaman di-resume dari state lama dan menembakkan request yang konteksnya sudah tidak valid.
Polling status terlalu agresif saat jaringan naik-turun.
Header cache atau state lokal klien membuat data lama terlihat masih benar.

Dari sisi backend, gejalanya sering muncul sebagai:

Duplikasi job untuk aksi yang sama.
Worker memproses item yang sama dua kali karena timeout visibilitas terlalu pendek.
Lock bocor karena proses mati mendadak.
Cache tidak dibersihkan setelah worker berhasil menulis data baru.
Retry tanpa backoff yang memperburuk lonjakan beban saat incident.

Karena itu, tujuan desainnya bukan membuat request selalu berhasil dalam sekali kirim, melainkan membuat sistem aman saat request gagal, terulang, atau tiba tidak berurutan.

Arsitektur queue + worker yang lebih tahan gangguan

Prinsip dasar

Pisahkan jalur request handling dan job execution:

API menerima request dari browser konsol.
API memvalidasi input dan memeriksa idempotency key.
Jika request baru, API menyimpan jejak permintaan dan mendorong job ke queue.
API segera mengembalikan respons seperti 202 Accepted atau status yang setara, beserta operation_id.
Worker mengambil job, memasang lock, menjalankan proses bisnis, memperbarui status, lalu menghapus atau memperbarui cache terkait.
Klien melakukan polling status atau mengambil hasil dari endpoint terpisah.

Dengan model ini, timeout di sisi browser tidak otomatis berarti pekerjaan gagal. Jika browser mengirim ulang request yang sama, backend dapat menjawab berdasarkan status operasi yang sudah tercatat, bukan menjalankan pekerjaan dari awal.

Alur request yang aman

Browser Console
  -> POST /purchase { idempotency_key, payload }
API
  -> cek tabel idempotency / operation store
  -> jika belum ada: simpan operation(status=pending)
  -> enqueue job(operation_id)
  -> return 202 { operation_id, status: "pending" }

Worker
  -> dequeue job(operation_id)
  -> ambil distributed lock(resource)
  -> jalankan operasi bisnis
  -> update operation(status=done|failed)
  -> invalidate / refresh cache
  -> release lock

Browser Console
  -> GET /operations/{operation_id}
  -> dapat status terkini tanpa memicu kerja ulang

Pola ini sederhana, tetapi sangat efektif untuk mengatasi request yang terputus, terduplikasi, atau datang ulang setelah resume jaringan.

Idempotency key: pertahanan pertama terhadap duplikasi

Mengapa wajib ada

Queue tidak otomatis menyelesaikan masalah duplikasi. Jika API menerima dua POST identik lalu mendorong dua job berbeda, duplikasi tetap terjadi. Karena itu, operasi yang punya efek samping—misalnya pembelian, sinkronisasi inventori, pembuatan sesi, atau trigger email—perlu memakai idempotency key.

Idempotency key adalah pengenal unik per aksi logis, bukan per koneksi HTTP. Jika browser mengirim ulang request yang sama, backend harus menganggapnya sebagai percobaan ulang atas aksi yang sama.

Praktik implementasi

Minta klien mengirim header atau field seperti Idempotency-Key.
Simpan key bersama identitas pemiliknya, misalnya user_id, tipe operasi, hash payload penting, status, dan hasil terakhir.
Terapkan unique constraint di penyimpanan agar dua request paralel tidak membuat dua record berbeda.
Jika key yang sama datang lagi dengan payload berbeda, anggap sebagai error, bukan retry valid.
Tetapkan TTL retensi sesuai karakter operasi. Terlalu pendek membuat duplikasi lolos; terlalu lama memperbesar storage.

Contoh skema penyimpanan

idempotency_records
- id
- user_id
- operation_type
- idempotency_key
- request_hash
- operation_id
- status         -- pending, done, failed
- response_code
- response_body  -- opsional, bila ingin replay response
- created_at
- expires_at

UNIQUE (user_id, operation_type, idempotency_key)

Jika request ulang datang saat status masih pending, API cukup mengembalikan operation_id yang sama. Jika sudah done, API dapat mengembalikan hasil lama atau status selesai. Inilah yang membuat retry dari browser konsol menjadi aman.

Kesalahan umum

Menggunakan fingerprint payload saja tanpa key eksplisit, sehingga perubahan kecil pada field non-esensial membuat request dianggap baru.
Menyimpan key hanya di memori proses API. Begitu proses restart, perlindungan hilang.
Tidak memberi unique constraint di database, sehingga balapan antar node tetap bisa membuat duplikasi.

Queue semantics: visibility timeout, ack, dan retry

Kenapa visibility timeout penting

Pada banyak sistem queue, ketika worker mengambil job, job itu disembunyikan sementara selama visibility timeout. Jika worker berhasil dan mengakui penyelesaian job sebelum batas waktu, job dianggap selesai. Jika worker mati atau tidak mengirim ack, job akan terlihat lagi dan bisa diproses ulang.

Ini berguna untuk keandalan, tetapi juga sumber duplikasi bila timeout terlalu pendek. Misalnya, worker memproses job selama 90 detik, tetapi visibility timeout hanya 30 detik. Job yang sama bisa diambil worker lain sebelum eksekusi pertama selesai.

Panduan penentuan timeout

Set visibility timeout lebih panjang dari durasi normal job, ditambah buffer untuk lonjakan.
Untuk job panjang, gunakan mekanisme heartbeat atau perpanjangan lease bila tersedia.
Pastikan operasi worker tetap idempoten karena timeout dan redelivery tetap bisa terjadi.

Retry yang sehat

Retry perlu dibedakan antara retry transport dan retry bisnis:

Retry transport: timeout jaringan, koneksi ke service lain putus, transient failure.
Retry bisnis: validasi gagal, saldo tidak cukup, resource tidak ditemukan. Ini biasanya tidak pantas di-retry berkali-kali.

Gunakan strategi berikut:

Exponential backoff untuk error transient.
Jitter agar retry dari banyak worker tidak serempak.
Batas maksimum percobaan yang jelas.
Klasifikasi error yang bisa dan tidak bisa di-retry.

attempt 1 -> delay 5s
attempt 2 -> delay 15s
attempt 3 -> delay 45s
attempt 4 -> delay 2m + jitter
then -> dead-letter queue

Jangan membuat retry instan tanpa jeda. Saat service dependency sedang bermasalah, retry agresif hanya mempercepat antrean menumpuk dan memperburuk incident.

Dead-letter queue

Jika job sudah melewati batas retry, pindahkan ke dead-letter queue (DLQ). DLQ bukan tempat sampah yang dilupakan, tetapi area isolasi untuk analisis dan replay terkontrol.

Simpan metadata yang cukup:

operation_id
idempotency_key
jumlah attempt
error terakhir
dependency yang gagal
waktu pertama dan terakhir diproses

Data ini penting untuk membedakan apakah masalah berasal dari payload, bug kode, lock contention, atau dependency eksternal.

Distributed lock: mencegah eksekusi paralel yang merusak

Kapan lock diperlukan

Idempotency key mencegah aksi logis dibuat dua kali dari pintu masuk API, tetapi tidak selalu cukup untuk melindungi resource di tahap worker. Anda masih butuh distributed lock jika dua job berbeda bisa menyentuh resource yang sama secara bersamaan, misalnya:

Dua sinkronisasi untuk akun yang sama.
Pembaruan inventory item yang sama.
Refresh cache mahal untuk key identik.
Penyelesaian order yang harus serial per user atau per cart.

Prinsip lock yang aman

Lock harus punya TTL agar tidak bocor permanen jika worker mati.
Lock harus menyimpan token pemilik; hanya pemilik sah yang boleh melepas lock.
TTL harus lebih panjang dari pekerjaan normal, atau bisa diperpanjang dengan heartbeat.
Jangan andalkan lock sebagai satu-satunya mekanisme integritas data; tetap gunakan constraint database bila perlu.

Redis vs database lock: trade-off praktis

Redis lock cocok bila Anda butuh lock cepat, sederhana, dan berumur pendek untuk koordinasi worker.

Kelebihan: latensi rendah, TTL alami, cocok untuk lock sementara.
Kekurangan: perlu disiplin implementasi token ownership, sensitif terhadap expiry yang terlalu cepat, dan tidak menggantikan transaksi data utama.

Database lock cocok bila konsistensi lock harus dekat dengan data yang dimutasi, atau saat Anda ingin menggabungkan kontrol konkurensi dengan transaksi.

Kelebihan: lebih dekat ke sumber kebenaran data, bisa dipadukan dengan unique constraint atau row-level control.
Kekurangan: lebih berat, berpotensi menambah contention, dan kurang ideal untuk lock frekuensi tinggi dengan durasi singkat.

Kapan memilih yang mana?

Pilih Redis untuk koordinasi worker dan serialisasi kerja jangka pendek.
Pilih database jika integritas operasi sangat bergantung pada data yang sama dan Anda sudah perlu transaksi di sana.
Untuk operasi kritis, kombinasi keduanya sering masuk akal: Redis untuk throttle konkurensi, database constraint untuk pagar terakhir.

Contoh pola lock dengan token

lock_key = "lock:order:123"
owner_token = random_uuid()

# acquire jika belum ada, dengan TTL
SET lock_key owner_token NX EX 120

# saat release, pastikan token cocok
if GET lock_key == owner_token:
  DEL lock_key

Inti dari pola ini: worker yang lock-nya sudah kedaluwarsa tidak boleh sembarangan menghapus lock milik worker lain yang datang belakangan.

Kegagalan lock yang sering terjadi

TTL terlalu pendek, lock habis sebelum job selesai, lalu worker kedua masuk.
Release lock tanpa memeriksa token pemilik.
Tidak ada monitoring untuk lock tua yang menandakan worker macet.
Lock dipakai menggantikan desain idempoten, sehingga sistem rapuh saat redelivery terjadi.

Cache stale dan invalidation setelah worker selesai

Kenapa browser konsol memperburuk masalah cache

Klien dengan resume buruk bisa membaca data lama, lalu memicu operasi berdasarkan state yang sudah usang. Di sisi backend, cache stale menambah kebingungan: worker sudah selesai memperbarui data, tetapi endpoint status atau resource masih mengembalikan nilai lama.

Karena itu, setiap job yang mengubah state harus jelas efeknya terhadap cache.

Pola invalidasi yang aman

Cache-aside: setelah write berhasil, hapus key terkait agar pembacaan berikutnya mengambil data baru dari sumber utama.
Versioned key: simpan versi atau revision pada resource, lalu key cache ikut berubah saat data berubah.
Status operation terpisah: jangan campur cache data hasil dengan status progres job; endpoint status harus membaca sumber yang lebih konsisten.

Hindari menghapus cache terlalu dini. Jika worker gagal di tengah jalan setelah cache dibersihkan tetapi data utama belum konsisten, klien bisa membaca keadaan setengah jadi. Idealnya invalidasi dilakukan setelah transaksi utama benar-benar sukses.

Kesalahan umum pada cache

Meng-cache status pending terlalu lama sehingga klien mengira job belum selesai.
Tidak mengaitkan invalidasi cache dengan event sukses worker.
Menggunakan TTL cache sebagai pengganti invalidasi eksplisit untuk data yang sensitif terhadap freshness.

Contoh alur end-to-end

Kasus: sinkronisasi inventori pengguna

Misalkan browser console memicu sinkronisasi inventori setelah login. Karena koneksi tidak stabil, request bisa terkirim dua kali.

Klien mengirim POST /inventory/sync dengan Idempotency-Key.
API membuat atau menemukan record operasi yang sama.
API menaruh job sync_inventory(operation_id, user_id) ke queue dan mengembalikan 202.
Worker mengambil job, memasang lock per user_id agar dua sinkronisasi user yang sama tidak berjalan paralel.
Worker mengambil data dari dependency eksternal.
Worker menulis perubahan dalam transaksi, memperbarui status operasi, lalu menghapus cache inventory user.
Klien memanggil GET /operations/{operation_id} sampai status done, lalu mengambil inventory terbaru.

Jika request awal terulang, API tidak membuat job baru. Jika worker mati di tengah jalan, queue dapat mengirim ulang job. Karena operasi dikunci per user dan penulisan dibuat idempoten, redelivery tidak merusak data.

Failure mode yang perlu diantisipasi

Duplicate enqueue: API menerima request dua kali sebelum idempotency record tersimpan dengan aman.
Double processing: visibility timeout habis saat job masih berjalan.
Leaked lock: worker crash setelah lock terpasang.
Poison message: payload tertentu selalu memicu crash dan terus di-retry.
Cache stale: data utama berubah, cache lama tetap tersaji.
Retry storm: dependency lambat menyebabkan ribuan job retry bersamaan.
Status drift: operation store menyatakan done, tetapi efek samping eksternal sebenarnya belum tuntas.
Out-of-order completion: dua operasi terkait selesai dalam urutan yang tidak diharapkan.

Daftar ini penting untuk dijadikan bahan uji beban dan chaos testing, bukan hanya dokumentasi.

Observability: tanpa ini, queue hanya terlihat “lama”

Metrik minimum

Panjang antrean per tipe job.
Waktu tunggu job di queue.
Durasi eksekusi job.
Tingkat sukses, gagal, retry, dan DLQ.
Jumlah lock acquisition gagal.
Persentase request yang terkena idempotency replay.
Cache hit/miss untuk key penting.

Logging dan tracing

Gunakan korelasi ID yang konsisten dari API ke worker:

request_id
operation_id
idempotency_key
job_id
resource_id yang di-lock

Dengan korelasi ini, Anda bisa menjawab pertanyaan seperti: “Apakah request user diproses dua kali?”, “Kenapa status pending terlalu lama?”, atau “Job mana yang mengunci resource ini?”

Alert yang berguna

Antrean tumbuh terus selama beberapa menit.
DLQ bertambah cepat.
Lock tua melebihi ambang normal.
Retry rate melonjak pada satu dependency.
P95 durasi job meningkat tajam.

Alert yang baik harus menunjuk gejala operasional, bukan hanya CPU atau memori worker.

Runbook insiden untuk queue worker browser konsol

Saat insiden terjadi, tim sering tahu “ada backlog”, tetapi tidak tahu tindakan pertama. Buat runbook yang konkret.

1. Antrean menumpuk

Periksa apakah masalah ada di dependency eksternal, lock contention, atau worker crash loop.
Lihat distribusi tipe job; jangan asumsikan semua job bermasalah.
Jika perlu, turunkan laju konsumsi job tertentu atau hentikan enqueue non-kritis.

2. Retry storm

Identifikasi error transient yang dominan.
Aktifkan atau perbesar backoff dan jitter bila configurable.
Pertimbangkan circuit breaker ke dependency yang sedang rusak.
Hindari replay massal sebelum akar masalah dipahami.

3. Lock bocor atau contention tinggi

Audit lock yang usianya melebihi durasi kerja normal.
Periksa apakah worker mati sebelum release.
Validasi TTL lock dan mekanisme ownership token.
Jika harus membersihkan lock manual, pastikan resource tidak sedang diproses worker lain.

4. DLQ meningkat

Kelompokkan berdasarkan signature error, bukan per pesan tunggal.
Bedakan bug kode, payload buruk, dan dependency gagal.
Replay hanya setelah penyebabnya ditangani.

5. Cache stale setelah job sukses

Bandingkan timestamp update data utama dan cache.
Periksa apakah invalidasi dilakukan sebelum commit atau setelahnya.
Pastikan endpoint status tidak membaca cache yang salah lapisan.

Runbook yang baik berisi langkah diagnosis, metrik yang dicek, query/log yang dicari, dan keputusan kapan replay job aman dilakukan.

Checklist implementasi produksi

Operasi dengan efek samping memakai idempotency key.
Ada unique constraint untuk mencegah balapan saat request ganda masuk bersamaan.
API mengembalikan operation_id dan tidak memaksa klien menunggu kerja berat selesai.
Worker menganggap redelivery bisa terjadi kapan saja.
Visibility timeout lebih panjang dari durasi kerja normal atau dapat diperpanjang.
Retry policy memakai backoff + jitter dan klasifikasi error yang jelas.
Dead-letter queue aktif dengan metadata yang memadai.
Distributed lock punya TTL dan token kepemilikan.
Integritas data penting tetap dilindungi constraint database atau transaksi yang sesuai.
Cache invalidation terjadi setelah write sukses, bukan sekadar menunggu TTL habis.
Ada metrik antrean, retry, lock, DLQ, dan durasi job.
Log API dan worker terhubung lewat correlation ID.
Ada runbook untuk backlog, retry storm, lock leak, dan replay DLQ.
Uji dengan simulasi: request duplikat, timeout, worker crash, lock expiry, dan dependency lambat.

Penutup

Merancang backend untuk browser konsol pada dasarnya adalah latihan menghadapi klien yang tidak bisa diandalkan sepenuhnya. Solusi yang efektif bukan sekadar menambah queue, tetapi membangun sistem yang aman terhadap duplikasi, timeout, dan eksekusi ulang. Kombinasi queue + worker, idempotency key, visibility timeout yang tepat, distributed lock, invalidasi cache yang disiplin, retry dengan backoff, DLQ, dan observability yang baik akan membuat backend tetap konsisten meskipun perilaku klien berantakan.

Jika Anda hanya mengambil satu prinsip dari artikel ini, ambil yang ini: anggap setiap request bisa datang lebih dari sekali, setiap job bisa diproses ulang, dan setiap lock bisa gagal dilepas. Dengan asumsi itu, desain backend Anda akan jauh lebih siap menghadapi browser konsol dan klien aneh lainnya.

Quick Search

shopping_cart Keranjang