Ownership Debugging: Studi Kasus Latensi Cache Redis API menjawab langsung masalah utama: mengapa endpoint order-show tiba-tiba jadi lambat setelah deploy tanpa ada perubahan logis di kode bisnis. Dalam dua paragraf awal ini terjadi pengenalan gejala dan tanggung jawab tim yang memegang kepemilikan layanan API tersebut.

Gejala Latensi yang Terlihat

Beberapa menit setelah deploy versi baru, monitoring API menunjukkan P95 naik dari ~120ms menjadi 450ms di endpoint /api/orders/{id}. Tidak ada peningkatan jumlah request, tapi user session mengalami timeout cache ketika memanggil informasi lengkap order. Tim layanan cache menerima beberapa laporan timeout dari tim support.

Gejala lain: semua panggilan ke cache Redis menunjukkan cold miss tinggi, sedangkan hit ratio sebelumnya stabil di 92%. Pengamatan awal menegaskan latensi bukan karena database transaksi, melainkan lapisan caching yang seharusnya mempercepat respon.

Triage Observabilitas

Logs: Konsistensi dan Waktu Eksekusi

Log request API mencatat mulai dan selesai handling cache. Setelah deploy tercatat banyak log mencatat status cache locked dengan durasi tunggu hingga 300ms. Log detail middleware caching memberikan indikasi bahwa lock internal (cache stampede prevention) menahan request lebih lama dibandingkan sebelum deploy.

Metrics: Redis dan API

Metrik Redis menunjukkan peningkatan blocked connections sejak tempo implementasi patch cache lock. Concurrent connections naik dari steady 120 ke 600 karena timeout lock yang dikunci per key. Metric instrumentation pada API memperlihatkan spike CPU di service, sebab worker menunggu timeout lock daripada mengambil data langsung.

Traces: Context Propagation

Distributed tracing (OpenTelemetry) memancing trace child call ke Redis selama 350ms diselingi latency yang tidak konsisten. Trace korelasi memperlihatkan bahwa lock mengambil TTL default 5 detik, tapi requests yang scale tinggi menunggu expiration hingga masih aktif, sehingga pipeline kerja terhenti bergantian.

Identifikasi Root Cause

Perubahan terakhir di repo cache menambahkan flag prevent cache stampede yang memakai SETNX lalu polling hingga TTL berakhir. Namun flag itu tidak mempertimbangkan cache key scope dan TTL untuk data yang sangat sering diupdate. Saat traffic burst terjadi, semua worker memblok satu key tunggal.

Selain itu, configuration patch prod menulis cache.lock.ttl: 5000 tanpa fallback ke shorter TTL, sehingga redis lock tidak segera expire bila service mengalami GC pause. Artinya, lock yang seharusnya cepat mati malah menahan sementara pool worker menunggu.

Perbaikan dan Tuning

Langkah konkret yang diambil:

  • Mengubah pendekatan locking dengan membatasi scope ke key per user dan menambahkan jitter, bukan global lock.
  • Menurunkan TTL lock agar worker dapat segera mencoba lagi, dengan fallback cache.lock.ttl: 1000 dan cache.lock.retry-interval: 50 ms.
  • Menambahkan observability untuk cache lock duration agar alert bisa memicu sebelum P95 naik.

Patch konfigurasi Redis (Spring Boot style) contohnya:

cache:
  redis:
    lock:
      ttl: 1000
      retryInterval: 50
      scope: user-order

Setelah patch, dilanjutkan regression check: memutar ulang scenario load test 3x memanfaatkan perhitungan kunci key per user dan memverifikasi P95 tetap di bawah 200ms. Observability tambahan berupa metric cache.lock.wait.ms segera memberi respon jika lock time naik.

Pembelajaran Ownership yang Berkelanjutan

Ownership berarti siapa pun yang merilis patch juga bertanggung jawab memantau dampaknya. Checklist pasca-debugging:

  • Verifikasi perbaikan melalui end-to-end test yang meniru pola update cache.
  • Pastikan observability memperlihatkan lead time lock dan TTL nyata.
  • Dokumentasikan behavior baru agar tim support dan DevOps tahu batas threshold lock.
  • Pastikan regression test menutup celah agar penambahan lock tidak menurunkan throughput di burst berikutnya.

Ownership debugging bukan hanya menyelesaikan issue sekali, tapi menjaga SLA dengan memverifikasi stability, menyiapkan alat monitoring yang menangkap rerata kendala, dan menegaskan siapa memikul tanggung jawab operasi sehari-hari.