Rust Worker Queue yang andal tidak cukup hanya bisa mengambil job dari antrean dan mengeksekusinya. Di produksi, masalah utamanya biasanya muncul saat sistem gagal pada waktu yang salah: worker crash di tengah proses, job diproses dua kali, lock Redis kedaluwarsa sebelum kerja selesai, retry berjalan serempak dan memukul service downstream, atau data berubah setengah jalan sehingga hasil akhir tidak konsisten.

Solusi praktisnya adalah menggabungkan beberapa mekanisme yang saling melengkapi: idempotensi untuk menahan duplikasi, distributed lock untuk membatasi eksekusi paralel pada entitas yang sama, visibility timeout agar job bisa diambil ulang jika worker hilang, retry dengan backoff dan jitter untuk mencegah retry storm, dan dead-letter handling untuk job poison yang terus gagal. Rust cocok untuk ini karena type system dan model konkurensinya membantu mengurangi bug state dan race condition, tetapi desain antriannya tetap harus benar.

Arsitektur sederhana producer-consumer untuk worker queue

Arsitektur minimal yang realistis biasanya terdiri dari komponen berikut:

  • Producer: membuat job dan memasukkannya ke antrean.
  • Queue backend: menyimpan job siap proses.
  • In-flight store: menyimpan job yang sedang diproses beserta deadline visibility timeout.
  • Worker: mengambil job, menjalankan handler, lalu ack atau reschedule.
  • Redis lock: membatasi eksekusi bersamaan untuk resource atau aggregate key tertentu.
  • Persistent state: database aplikasi untuk hasil akhir dan idempotency record.
  • DLQ / failed queue: menampung job yang sudah tidak layak di-retry otomatis.

Secara logis, alurnya seperti ini:

  1. Producer mengirim job dengan job_id, idempotency_key, payload, dan metadata retry.
  2. Worker mengambil job dari antrean, lalu memindahkannya ke status in-flight dengan visibility timeout.
  3. Worker mengambil lock Redis berdasarkan kunci bisnis, misalnya payment:{order_id}.
  4. Worker memeriksa idempotency store sebelum menjalankan efek samping.
  5. Jika sukses, worker menyimpan hasil dan meng-ack job.
  6. Jika gagal sementara, job dijadwalkan ulang dengan backoff.
  7. Jika gagal permanen atau melebihi batas retry, job dipindahkan ke DLQ.

Catatan penting: lock Redis bukan pengganti idempotensi. Lock membantu mencegah kerja paralel yang tidak diinginkan, tetapi tidak menjamin job tidak akan diproses dua kali, terutama saat worker crash, lock expire, atau jaringan bermasalah.

Struktur data job yang aman untuk retry

Job sebaiknya membawa metadata yang cukup untuk pengendalian eksekusi. Hindari payload yang hanya berisi data mentah tanpa konteks retry dan identitas unik.

use serde::{Deserialize, Serialize};
use std::collections::HashMap;

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct JobEnvelope<T> {
    pub job_id: String,
    pub job_type: String,
    pub idempotency_key: String,
    pub attempt: u32,
    pub max_attempts: u32,
    pub visible_at_epoch_ms: i64,
    pub created_at_epoch_ms: i64,
    pub trace_id: Option<String>,
    pub lock_key: Option<String>,
    pub headers: HashMap<String, String>,
    pub payload: T,
}

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct SendEmailJob {
    pub user_id: String,
    pub template: String,
    pub to: String,
}

Beberapa field penting:

  • job_id: identitas teknis job di queue.
  • idempotency_key: identitas operasi bisnis. Ini yang dipakai untuk menahan duplikasi efek samping.
  • attempt dan max_attempts: dasar retry policy.
  • visible_at: mendukung delayed retry dan scheduling.
  • lock_key: resource yang harus diproses eksklusif, misalnya satu order, satu invoice, atau satu akun.
  • trace_id: memudahkan korelasi log dan tracing.

Kesalahan umum: memakai job_id sebagai idempotency key. Jika producer menerbitkan ulang job yang sama secara semantik dengan job_id baru, sistem tetap menggandakan efek samping. Idempotency key harus merepresentasikan operasi bisnis, bukan sekadar pesan teknis.

Idempotensi: garis pertahanan utama terhadap job ganda

Jika worker queue Anda minimal sekali-kirim (at-least-once delivery), maka duplikasi bukan kemungkinan kecil, melainkan perilaku normal yang harus diantisipasi. Idempotensi memastikan operasi yang sama tidak menghasilkan efek samping berulang.

Pola implementasi idempotensi

Pola yang paling aman biasanya:

  1. Sebelum menjalankan efek samping, buat atau cek record idempotensi di storage yang persisten.
  2. Jika status sudah completed, kembalikan hasil lama atau anggap job sukses tanpa mengulang kerja.
  3. Jika status processing, tentukan apakah worker lain masih valid atau record sudah stale.
  4. Jika belum ada, buat record baru secara atomik.
  5. Setelah efek samping sukses, tandai completed.

Contoh skema status:

  • processing: operasi sedang berjalan.
  • completed: operasi sudah berhasil.
  • failed: operasi gagal permanen atau perlu investigasi manual.

Di tingkat database, implementasi idealnya memakai constraint unik pada idempotency_key. Dengan begitu, dua worker yang balapan tidak sama-sama merasa mendapat hak eksekusi.

// pseudo-code, detail DB disederhanakan
async fn begin_idempotent_op(
    repo: &IdempotencyRepo,
    key: &str,
) -> anyhow::Result<BeginResult> {
    match repo.try_insert_processing(key).await? {
        true => Ok(BeginResult::Started),
        false => {
            let state = repo.get(key).await?;
            match state.status.as_str() {
                "completed" => Ok(BeginResult::AlreadyCompleted(state.result)),
                "processing" => Ok(BeginResult::InProgress),
                _ => Ok(BeginResult::RetryableConflict),
            }
        }
    }
}

Mengapa ini bekerja? Karena keputusan final tidak bergantung pada memori worker atau lock sementara di Redis, tetapi pada storage persisten yang dapat bertahan setelah crash. Ini penting untuk efek samping seperti membuat invoice, menagih pembayaran, mengirim email, atau mengubah saldo.

Kapan lock saja tidak cukup

Misalkan worker A memegang lock Redis lalu memanggil API pembayaran. Sebelum sempat menandai sukses di database, worker A crash. Lock lalu kedaluwarsa. Worker B mengambil job yang sama dan mengeksekusinya lagi. Tanpa idempotensi pada sisi aplikasi atau downstream API, pembayaran bisa tertagih dua kali.

Jadi, gunakan pendekatan berlapis:

  • Lock Redis untuk mengurangi paralelisme yang berbahaya.
  • Idempotency store untuk mencegah duplikasi efek samping.
  • Idempotent downstream API jika tersedia, misalnya header idempotency pada service eksternal.

Distributed lock Redis: kapan dipakai dan apa risikonya

Distributed lock berbasis Redis berguna saat Anda ingin mencegah dua worker memproses resource yang sama secara bersamaan. Ini umum pada kasus seperti rekonsiliasi invoice, sinkronisasi data akun, atau update state order yang harus serial per entity.

Pola lock yang aman secara minimum

Untuk implementasi dasar, gunakan operasi atomik set-if-not-exists dengan TTL, lalu simpan token acak sebagai pemilik lock. Saat melepas lock, hapus hanya jika token masih cocok. Ini mencegah worker lain menghapus lock yang bukan miliknya.

use uuid::Uuid;

pub struct RedisLock {
    pub key: String,
    pub token: String,
    pub ttl_ms: u64,
}

async fn acquire_lock(
    redis: &RedisClient,
    key: &str,
    ttl_ms: u64,
) -> anyhow::Result<Option<RedisLock>> {
    let token = Uuid::new_v4().to_string();

    let acquired = redis
        .set_nx_with_px(key, &token, ttl_ms)
        .await?;

    if acquired {
        Ok(Some(RedisLock {
            key: key.to_string(),
            token,
            ttl_ms,
        }))
    } else {
        Ok(None)
    }
}

async fn release_lock(redis: &RedisClient, lock: &RedisLock) -> anyhow::Result<bool> {
    redis.compare_and_del(&lock.key, &lock.token).await
}

Di dunia nyata, compare_and_del biasanya dijalankan lewat script atomik di Redis agar pengecekan nilai dan penghapusan terjadi dalam satu langkah.

Masalah lock kedaluwarsa di tengah proses

Lock dengan TTL terlalu pendek berisiko habis saat job belum selesai. Begitu habis, worker lain bisa masuk dan memproses resource yang sama. Lock dengan TTL terlalu panjang juga buruk karena memperlambat pemulihan saat worker mati.

Mitigasinya:

  • Set TTL berdasarkan durasi kerja normal ditambah margin yang masuk akal.
  • Jika job bisa lama, lakukan lock renewal berkala oleh worker pemilik lock.
  • Renewal harus memverifikasi token pemilik, bukan sekadar memperpanjang key.
  • Jangan mengandalkan lock untuk menjamin exactly-once.
async fn renew_lock(redis: &RedisClient, lock: &RedisLock, ttl_ms: u64) -> anyhow::Result<bool> {
    redis.compare_and_expire(&lock.key, &lock.token, ttl_ms).await
}

Trade-off: renewal menambah kompleksitas. Jika handler Anda biasanya singkat, TTL statis yang konservatif plus idempotensi sering lebih sederhana dan cukup aman.

Kapan tidak perlu lock Redis

Jika operasi Anda sudah idempotent penuh dan backend data mampu menegakkan konsistensi melalui transaksi, unique constraint, atau optimistic concurrency control, lock Redis bisa menjadi beban tambahan. Jangan menambah lock hanya karena antrean terdistribusi; tambahkan hanya jika ada resource contention yang nyata.

Visibility timeout dan crash worker di tengah proses

Visibility timeout berarti job yang sedang diproses disembunyikan sementara dari worker lain. Jika worker selesai tepat waktu, job di-ack dan hilang dari antrean. Jika worker crash atau macet, timeout habis dan job muncul lagi untuk diambil ulang.

Ini penting karena kegagalan paling umum bukan hanya error eksplisit, tetapi worker berhenti sebelum ack: proses mati, pod di-evict, node restart, atau koneksi terputus setelah efek samping terjadi.

Alur dasar dengan in-flight queue

  1. Pop job dari ready queue.
  2. Simpan ke in-flight store dengan deadline visibility timeout.
  3. Jalankan handler.
  4. Jika sukses, hapus dari in-flight store dan tandai ack.
  5. Jika gagal retryable, jadwalkan ulang dengan delay.
  6. Jika worker hilang, sweeper mengembalikan job in-flight yang deadline-nya lewat ke ready queue.

Dengan Redis, pola ini sering dibuat memakai kombinasi struktur data seperti list atau sorted set. Detail implementasi bisa bervariasi, tetapi prinsipnya sama: job tidak langsung hilang saat diambil; ia baru benar-benar selesai setelah ack eksplisit.

Kesalahan umum: mengambil job dari list lalu langsung menghapusnya tanpa jejak in-flight. Jika worker crash setelah itu, job hilang permanen.

Perpanjangan visibility timeout

Jika handler bisa lebih lama dari visibility timeout, worker perlu heartbeat atau perpanjangan berkala. Tanpa ini, job bisa muncul lagi walau proses lama masih berjalan. Efeknya adalah duplikasi eksekusi.

Namun, semakin sering Anda memperpanjang timeout, semakin besar pula kemungkinan job macet tidak cepat dipulihkan jika worker sebenarnya hang. Solusinya biasanya:

  • Gunakan timeout dasar yang mencerminkan durasi normal.
  • Perpanjang hanya saat progres masih hidup.
  • Pasang batas maksimal total runtime per job.
  • Pastikan handler bisa dibatalkan atau di-timeout.

Retry aman dengan backoff, jitter, dan klasifikasi error

Tidak semua kegagalan layak di-retry. Worker queue yang sehat harus bisa membedakan:

  • Retryable: timeout jaringan, rate limit sementara, service downstream 5xx, deadlock database yang sementara.
  • Non-retryable: payload invalid, referensi data tidak ada, kontrak API salah, bug logika yang deterministik.

Tanpa klasifikasi ini, Anda berisiko menciptakan retry storm: banyak worker serempak mengulang request yang pasti gagal atau belum siap, membebani sistem lain dan memperburuk outage.

Backoff eksponensial dengan jitter

Backoff memberi jeda yang makin besar di setiap percobaan. Jitter menambahkan unsur acak agar banyak job tidak bangun di detik yang sama.

fn compute_retry_delay_ms(attempt: u32, base_ms: u64, max_ms: u64) -> u64 {
    let exp = 2u64.saturating_pow(attempt.min(10));
    let raw = base_ms.saturating_mul(exp).min(max_ms);

    // jitter sederhana: 50% - 100% dari raw
    let jitter = fastrand::u64((raw / 2)..=raw.max(1));
    jitter
}

Praktiknya:

  • Gunakan base kecil untuk error sementara yang biasa pulih cepat.
  • Beri cap maksimal agar delay tidak membesar tanpa batas.
  • Tambahkan jitter untuk menyebar beban.
  • Simpan attempt di metadata job, bukan hanya di memori worker.

Klasifikasi error di Rust

Lebih aman jika handler mengembalikan tipe error yang eksplisit, bukan hanya string.

#[derive(Debug)]
pub enum JobError {
    Retryable(anyhow::Error),
    Permanent(anyhow::Error),
}

async fn process_job(job: &JobEnvelope<SendEmailJob>) -> Result<(), JobError> {
    // validasi payload
    if job.payload.to.is_empty() {
        return Err(JobError::Permanent(anyhow::anyhow!("recipient kosong")));
    }

    // panggil service eksternal
    let result = call_email_provider(job).await;
    match result {
        Ok(_) => Ok(()),
        Err(e) if e.is_timeout() || e.is_rate_limited() => {
            Err(JobError::Retryable(anyhow::anyhow!(e)))
        }
        Err(e) => Err(JobError::Permanent(anyhow::anyhow!(e))),
    }
}

Mengapa penting? Karena keputusan retry adalah bagian dari kontrak handler. Jika semua error diperlakukan sama, operasional queue akan kacau: terlalu agresif saat service eksternal rusak, atau terlalu pasif saat gangguan sebenarnya sementara.

Menangani job poison dan dead-letter queue

Job poison adalah job yang hampir pasti gagal terus, misalnya payload korup, data referensi sudah dihapus, atau ada bug deterministik pada path tertentu. Jika Anda terus me-retry job seperti ini, antrean akan tersumbat dan metric gagal menjadi tidak informatif.

Kapan job dipindahkan ke DLQ

  • Jumlah attempt melebihi max_attempts.
  • Error diklasifikasikan permanen.
  • Total umur job melewati SLA tertentu.
  • Payload terbukti invalid dan tidak dapat diperbaiki otomatis.

Simpan alasan kegagalan terakhir, stack context yang relevan, attempt count, dan timestamp. Ini akan sangat membantu saat investigasi.

DLQ sebaiknya tidak menjadi kuburan data. Buat prosedur jelas:

  • Siapa yang memonitor DLQ.
  • Kapan job bisa direplay.
  • Bagaimana mencegah replay massal yang memicu ulang masalah yang sama.

Contoh loop worker Rust yang menggabungkan semua mekanisme

Berikut pseudo-code yang menyatukan visibility timeout, lock, idempotensi, dan retry. Detail API disederhanakan agar fokus pada alur.

async fn worker_loop(ctx: WorkerContext) -> anyhow::Result<()> {
    loop {
        let Some(job) = ctx.queue.reserve_next().await? else {
            ctx.sleep_short().await;
            continue;
        };

        let _span = ctx.tracer.start_job_span(&job.job_id, &job.job_type, job.trace_id.as_deref());
        ctx.metrics.job_received(&job.job_type);

        let lock = if let Some(lock_key) = &job.lock_key {
            match acquire_lock(&ctx.redis, lock_key, ctx.config.lock_ttl_ms).await? {
                Some(lock) => Some(lock),
                None => {
                    ctx.queue.reschedule(job, ctx.config.lock_conflict_delay_ms).await?;
                    ctx.metrics.job_lock_conflict(&job.job_type);
                    continue;
                }
            }
        } else {
            None
        };

        let result = match begin_idempotent_op(&ctx.idempotency_repo, &job.idempotency_key).await? {
            BeginResult::AlreadyCompleted(_) => {
                ctx.queue.ack(&job.job_id).await?;
                ctx.metrics.job_deduplicated(&job.job_type);
                Ok(())
            }
            BeginResult::InProgress => {
                ctx.queue.reschedule(job.clone(), ctx.config.in_progress_delay_ms).await?;
                Ok(())
            }
            BeginResult::Started | BeginResult::RetryableConflict => {
                process_job(&job).await.map_err(|e| e)
            }
        };

        match result {
            Ok(()) => {
                ctx.idempotency_repo.mark_completed(&job.idempotency_key).await?;
                ctx.queue.ack(&job.job_id).await?;
                ctx.metrics.job_success(&job.job_type);
            }
            Err(JobError::Retryable(err)) => {
                let next_attempt = job.attempt + 1;
                if next_attempt >= job.max_attempts {
                    ctx.idempotency_repo.mark_failed(&job.idempotency_key, &format!("{err:#}")).await?;
                    ctx.queue.move_to_dlq(job.clone(), &format!("{err:#}")).await?;
                    ctx.metrics.job_dlq(&job.job_type);
                } else {
                    let delay_ms = compute_retry_delay_ms(next_attempt, 500, 60_000);
                    let mut retried = job.clone();
                    retried.attempt = next_attempt;
                    ctx.queue.reschedule(retried, delay_ms).await?;
                    ctx.metrics.job_retry(&job.job_type);
                }
            }
            Err(JobError::Permanent(err)) => {
                ctx.idempotency_repo.mark_failed(&job.idempotency_key, &format!("{err:#}")).await?;
                ctx.queue.move_to_dlq(job.clone(), &format!("{err:#}")).await?;
                ctx.metrics.job_failed_permanent(&job.job_type);
            }
        }

        if let Some(lock) = lock {
            let _ = release_lock(&ctx.redis, &lock).await;
        }
    }
}

Hal yang perlu diperhatikan dari alur di atas:

  • Lock conflict tidak dianggap gagal keras; job cukup dijadwalkan ulang singkat.
  • Idempotensi dicek sebelum efek samping, bukan setelah.
  • Ack dilakukan hanya setelah state penting tersimpan.
  • Retryable dan Permanent dipisahkan dengan jelas.
  • Release lock sebaiknya dilakukan di blok finalisasi, tetapi tetap aman walau gagal sesekali karena TTL akan membersihkan.

Masalah operasional yang paling sering muncul

1. Job ganda walau sudah pakai lock

Penyebab umum:

  • Lock TTL habis sebelum proses selesai.
  • Worker crash setelah efek samping tetapi sebelum ack.
  • Producer mengirim ulang operasi yang sama dengan job_id baru.

Mitigasi:

  • Gunakan idempotency key yang stabil secara bisnis.
  • Tambahkan lock renewal jika perlu.
  • Gunakan downstream idempotency bila tersedia.

2. Lock kedaluwarsa dan worker lain mengambil alih

Ini tidak selalu bug; bisa jadi memang skenario pemulihan. Masalahnya muncul jika handler tidak idempotent. Tanda-tandanya adalah log menunjukkan dua worker memproses resource yang sama dalam rentang waktu berdekatan.

Mitigasi:

  • Log token lock, lock key, dan durasi proses.
  • Monitor rasio lock conflict.
  • Review TTL dan distribusi runtime job, bukan hanya rata-ratanya.

3. Data tidak konsisten setelah crash di tengah proses

Contohnya, email sudah terkirim tetapi row database belum ter-update. Atau pembayaran sudah dicatat di pihak ketiga tetapi status lokal masih pending.

Mitigasi:

  • Prioritaskan operasi yang bisa diulang aman.
  • Simpan status transisi secara eksplisit.
  • Jika perlu, gunakan pola outbox atau rekonsiliasi periodik terhadap sistem eksternal.

4. Retry storm saat dependency melambat

Gejalanya: throughput turun, attempt naik tajam, antrean membengkak, dan service downstream makin kewalahan.

Mitigasi:

  • Backoff eksponensial + jitter.
  • Concurrency limit per job type atau per downstream.
  • Circuit breaker atau rate limiting di sisi worker.
  • Bedakan error retryable dan permanent.

5. Poison job menahan antrean

Jika satu job selalu gagal cepat dan terus kembali ke depan antrean, worker akan membuang banyak siklus CPU untuk pekerjaan yang tidak akan pernah selesai.

Mitigasi:

  • Batas attempt yang jelas.
  • DLQ yang aktif dimonitor.
  • Validasi payload sedini mungkin sebelum kerja mahal dimulai.

Observability: log, metric, dan tracing yang benar-benar berguna

Worker queue sulit di-debug jika hanya mengandalkan log error akhir. Anda perlu observability yang bisa menjawab pertanyaan berikut:

  • Job mana yang diproses dua kali?
  • Berapa lama job menunggu di antrean?
  • Kapan retry melonjak?
  • Lock key mana yang paling sering bentrok?
  • Apakah timeout terjadi di queue, Redis, database, atau downstream API?

Logging

Gunakan structured logging. Minimal sertakan:

  • job_id
  • job_type
  • idempotency_key
  • attempt
  • lock_key
  • trace_id
  • duration_ms
  • error_kind

Hindari hanya menulis string panjang tanpa field terstruktur, karena nanti sulit difilter saat insiden.

Metric

Metric minimum yang sangat membantu:

  • queue_depth: jumlah job siap proses.
  • in_flight_jobs: jumlah job sedang diproses.
  • job_latency: umur job sejak dibuat sampai selesai.
  • processing_duration: durasi handler.
  • retry_count: jumlah retry per jenis job.
  • dlq_count: jumlah job masuk DLQ.
  • lock_conflict_count: frekuensi gagal acquire lock.
  • idempotency_hit_count: jumlah duplikasi yang berhasil ditahan.

Dengan metric ini, Anda bisa membedakan bottleneck di antrean, kontensi lock, atau dependency eksternal.

Tracing

Gunakan tracing untuk menghubungkan producer, worker, Redis, database, dan panggilan HTTP. Terutama jika satu operasi bisnis memicu beberapa job lanjutan. Trace yang baik akan memperlihatkan apakah masalah terjadi sebelum lock, saat query idempotensi, atau ketika memanggil service lain.

Trade-off desain yang perlu dipahami

At-least-once vs exactly-once

Di sistem terdistribusi, exactly-once end-to-end biasanya mahal dan sulit dibuktikan. Desain yang lebih realistis adalah at-least-once delivery + idempotent processing. Ini lebih mudah dioperasikan dan lebih jujur terhadap failure mode nyata.

Redis sebagai lock service

Redis cepat dan praktis, tetapi lock-nya berbasis TTL dan sensitif terhadap asumsi waktu proses. Cocok untuk mutual exclusion pragmatis, bukan untuk menjamin konsistensi bisnis akhir. Jika konsistensi final sangat kritis, pastikan database atau storage utama tetap menjadi sumber kebenaran.

Retry agresif vs melindungi downstream

Retry terlalu cepat mempercepat pemulihan pada error kecil, tetapi berbahaya saat ada outage lebih besar. Retry terlalu lambat melindungi dependency tetapi memperpanjang latency. Solusi praktisnya adalah klasifikasi error yang baik, limit concurrency, dan metric yang memberi umpan balik cepat.

Checklist mitigasi produksi untuk Rust worker queue

  • Gunakan idempotency key berbasis operasi bisnis, bukan job_id.
  • Simpan state idempotensi di storage persisten dengan constraint unik bila memungkinkan.
  • Terapkan visibility timeout dan mekanisme requeue untuk job in-flight yang kedaluwarsa.
  • Ack job hanya setelah state penting tersimpan dengan aman.
  • Gunakan lock Redis hanya untuk resource contention yang nyata.
  • Simpan token unik pada lock dan lakukan release/renew secara compare-and-set.
  • Tentukan TTL lock berdasarkan distribusi durasi kerja, bukan asumsi optimistis.
  • Pisahkan error retryable dan permanent.
  • Pakai backoff eksponensial dengan jitter untuk mencegah retry storm.
  • Batasi max_attempts dan pindahkan poison job ke DLQ.
  • Tambahkan concurrency limit per job type atau per dependency eksternal.
  • Pasang timeout pada panggilan I/O dan dukung cancellation.
  • Log field kunci secara terstruktur dan konsisten.
  • Ekspos metric antrean, retry, lock conflict, DLQ, dan idempotency hit.
  • Uji skenario crash: sebelum ack, setelah efek samping, saat lock expire, dan saat Redis tidak tersedia.

Penutup

Membangun Rust Worker Queue yang andal berarti menerima bahwa duplikasi, crash, dan retry bukan pengecualian, melainkan bagian dari operasi normal sistem terdistribusi. Karena itu, fokus utama bukan mengejar ilusi exactly-once, tetapi merancang pipeline yang tetap aman ketika hal-hal buruk terjadi.

Urutan prioritas yang biasanya paling efektif adalah: idempotensi terlebih dahulu, lalu visibility timeout, kemudian retry policy yang disiplin, dan terakhir lock Redis hanya di titik yang benar-benar memerlukan eksklusivitas. Jika observability Anda baik dan DLQ dikelola serius, worker queue Rust akan jauh lebih mudah dipelihara saat traffic naik atau dependency eksternal mulai tidak stabil.