Pendahuluan

Untuk sistem worker queue di cloud yang mengandalkan cache, tantangan utama adalah memastikan konsistensi ketika cache bisa stale dan lock distribusi tidak langsung tersedia. Strategi lock-tolerant menggabungkan proteksi distribusi dengan timeout/leaky bucket, cache prefetch dan invalidasi, serta cara mendeteksi retry deadlock, cache miss race, dan worker double-processing.

Artikel ini langsung membahas solusi praktis sehingga tim operasi dapat menerapkan arsitektur yang menjaga konsistensi data tanpa mengorbankan throughput.

1. Tantangan Operasional pada Worker Queue yang Bergantung pada Cache

Retry Deadlock dan Double-Processing

Ketika worker mengambil job dari queue dan cache dibaca sebelum lock terselesaikan, job bisa berulang diproses. Deadlock sering muncul ketika release lock gagal karena thread mati, sementara worker lain terus menunggu. Penyebab umum adalah timeout lock terlalu pendek atau tidak ada fallback.

Cache Miss Race

Race terjadi saat worker A menghapus cache dan menulis ke backend, sementara worker B membaca cache yang sudah invalid. Tanpa koordinasi, B bisa meneruskan data lama atau menulis kembali ke cache usang.

2. Arsitektur Lock-Tolerant untuk Queue dan Cache

Arsitektur sederhana menggabungkan tiga lapis:

 +-----------+       +------------+       +---------+
 | Queue     | ----> | Worker     | ----> | Service |
 | (Pub/Sub) |       | (Self-host |       | (DB     |
 +-----------+       |  + cache)  |       +---------+
                         |            |
                         v            v
                     +--------+    +--------+
                     | Redis  |    | etcd   |
                     | Lock/  |    | Lease  |
                     | Cache  |    +--------+
                     +--------+

Latar belakangnya adalah queue berisi job ringan, worker memerlukan cache untuk data reference, dan lock distribusi (Redis/etcd) memastikan hanya satu worker mengeksekusi write critical section.

Lock Distribusi dengan Timeout dan Leaky Bucket

Gunakan Redis atau etcd untuk lock per-key dengan TTL. TTL memastikan worker mati atau kehilangan lease tidak memblokir forever. Implementasikan leaky bucket untuk membatasi seberapa sering worker mencoba re-lock setelah gagal.

lockKey := fmt.Sprintf("lock:item:%s", itemID)
if tryAcquireRedisLock(lockKey, ttl) {
    defer releaseRedisLock(lockKey)
    processJob(itemID)
} else {
    backoff := calculateLeakyBucketDelay(itemID)
    sleep(backoff)
    retry(job)
}

Fungsi calculateLeakyBucketDelay mempertimbangkan berapa kali lock gagal (token leak) sehingga distribusi retry tidak mengakibatkan lonjakan beban.

3. Strategi Cache Prefetch dan Invalidasi

Pemecahan cache stale menggunakan dua pendekatan:

  • Prefetch data: ketika worker memegang lock, segera perbarui cache sebelum release. Cache hanya dikosongkan usai backend selesai. Jika invalidasi gagal, worker berikutnya membaca TTL pendek sebagai sinyal refresh.
  • Write-through dengan batching: gunakan queue tambahan (misalnya stream) untuk meneruskan perubahan sehingga cache bisa diperbarui secara konsisten tanpa race.

Contoh pseudo:

func processJob(itemID string) {
    // baca data dari DB
    data := readFromDB(itemID)
    writeCache(itemID, data, cacheTTL)
    updateExternal(data)
}

Jangan lupa membersihkan cache saat update gagal—tidak hanya saat sukses.

4. Observability dan Pemantauan Metrik

Monitoring harus mencakup:

  • Metrik lock: rata-rata waktu perolehan lock, retry per job, jumlah lock yang dilepas otomatis.
  • Metrik cache: hit ratio, waktu invalidasi, jumlah cache stale detected.
  • Queue health: job age, retry count, dan duplicate processing count.

Gunakan tracing untuk melihat hubungan antara lock acquisition, cache update, dan hasil job.

5. Implementasi dan Checklist Deployment

Sebelum deployment ke produksi, pastikan:

  • Lock TTL disesuaikan dengan p99 latency job plus margin recovery.
  • Leaky bucket/kalkulasi backoff diuji dengan skenario failure (misal: lock holder crash).
  • Cache invalidation logic mencakup fallback (cache purge, tombstone, atau versioning).
  • Worker melaporkan state retry/double-processing ke observability stack.
  • Retry deadlock ditandai dan ditangani melalui circuit breaker atau enqueued rollback job.

6. Troubleshooting

Jika lock gagal atau cache tidak sinkron, ikuti langkah berikut:

  1. Periksa log distribusi lock: apakah TTL terlalu pendek atau lock tidak dilepas? Jika ya, sesuaikan TTL dan lengkapi release pada defer.
  2. Validasi cache miss race: apakah worker membaca data lama sebelum cache refresh? Tambahkan versioning atau gunakan cache stampede guard dengan flag prefetch.
  3. Cek metrik retry/deadlock: jika retry tidak turun, pertimbangkan menambahkan backoff eksponensial atau memindahkan cache update ke job terpisah.
  4. Telusuri double-processing: gunakan trace id unik per job dan filter di observability untuk mengumpulkan kejadian ganda.

Jika cache tetap tidak sinkron, jalankan job kompensasi yang membaca DB dan menulis ulang cache dengan TTL pendek untuk mengembalikan konsistensi.

Penutup

Dengan kombinasi lock distribusi, strategi cache prefetched/invalidation, dan observability yang memadai, worker queue di cloud bisa tetap konsisten meskipun cache stale dan lock lambat. Jangan lupa menyesuaikan timeout, backoff, serta langkah troubleshooting agar sistem tetap dapat pulih secara otomatis.