Saat sebuah produk tiba-tiba mendapat eksposur besar—misalnya karena momentum eksternal seperti berita, kemitraan, atau pembahasan viral—backend sering gagal bukan pada jalur yang paling jelas, melainkan pada efek berantai: cache miss terjadi serentak, database dihantam ulang, queue membengkak, dan worker mengejar retry tanpa henti.

Untuk mencegah stampede cache dan queue banjir saat traffic meledak, Anda perlu kombinasi beberapa kontrol: read-through cache, TTL jitter, single-flight locking, stale-while-revalidate, rate limiting, backpressure, dead-letter queue, idempotensi job, visibilitas retry, dan metrik yang tepat. Kuncinya bukan membuat semua request selalu sukses, tetapi menjaga sistem tetap terkontrol saat beban melonjak tajam.

Konteks viral seperti berita tentang OpenAI atau Amazon bisa menjadi pemicu burst traffic. Namun masalah tekniknya bersifat umum: pola akses berubah mendadak, hotspot muncul, dan komponen yang biasanya aman menjadi bottleneck dalam hitungan detik.

Mengapa sistem runtuh saat traffic meledak

Ada tiga pola kegagalan yang sering muncul bersamaan:

  • Cache stampede: banyak request mengakses key yang sama, cache kedaluwarsa di waktu hampir bersamaan, lalu semua request fallback ke database atau service upstream.
  • Queue banjir: request sinkron mengubah pekerjaan berat menjadi async, tetapi tanpa pembatasan. Hasilnya queue menumpuk jauh lebih cepat daripada kapasitas worker.
  • Worker overload: worker memproses job terlalu lambat, gagal, lalu retry massal membuat antrian makin padat.

Masalah utamanya hampir selalu adalah sinkronisasi beban pada titik yang sama. Ribuan request ingin data yang sama, membuat job yang mirip, atau memicu retry pada waktu yang mirip. Karena itu solusinya juga harus memecah sinkronisasi tersebut.

Arsitektur dasar yang lebih tahan lonjakan

Alur request-worker-cache yang netral teknologi

Berikut alur yang umumnya lebih aman untuk endpoint yang sering diakses:

  1. Request masuk ke API.
  2. API cek cache.
  3. Jika cache hit, kembalikan respons segera.
  4. Jika cache stale tetapi masih dapat dipakai, kembalikan data stale dan jadwalkan refresh di background.
  5. Jika cache miss total, hanya satu request yang boleh membangun ulang data melalui lock single-flight.
  6. Request lain menunggu singkat, fallback ke stale, atau menerima respons degradasi yang terkontrol.
  7. Jika perlu kerja berat, job dikirim ke queue dengan batas enqueue dan idempotensi.
  8. Worker memproses job dengan concurrency yang dibatasi, retry yang terukur, dan DLQ untuk job bermasalah.
Client Request
    |
    v
 API / Gateway
    |
    +-- check cache(key)
    |      |
    |      +-- hit ---------> return data
    |      |
    |      +-- stale -------> return stale + trigger refresh async
    |      |
    |      +-- miss --------> acquire lock(single-flight)
    |                         |
    |                         +-- lock acquired ---> query DB/upstream
    |                         |                      set cache + release lock
    |                         |
    |                         +-- lock denied -----> wait short / fallback / 429
    |
    +-- optional enqueue job (bounded, idempotent)
               |
               v
            Queue
               |
               v
            Workers
               |
               +-- success -> ack
               +-- transient failure -> delayed retry
               +-- poison job -> dead-letter queue

Arsitektur ini bekerja karena memisahkan dua hal: jalur baca cepat dan jalur pembaruan yang dibatasi. Saat burst terjadi, tidak semua request diberi hak untuk memicu pekerjaan mahal.

Mencegah cache stampede

1. Gunakan read-through cache

Pola read-through cache membuat aplikasi selalu membaca lewat lapisan cache terlebih dahulu. Jika data belum ada, lapisan ini bertanggung jawab mengambil dari sumber data dan menulis balik ke cache.

Keuntungannya:

  • alur baca konsisten;
  • lebih mudah menambahkan lock, jitter, dan stale policy di satu tempat;
  • mengurangi logika cache yang tersebar di banyak endpoint.

Masalah umum terjadi ketika cache hanya menjadi optimasi parsial: sebagian endpoint membaca langsung ke database, sebagian tidak. Pada saat lonjakan, pola yang tidak seragam membuat perilaku sistem sulit diprediksi.

2. Tambahkan TTL jitter

Jika semua key penting memiliki TTL sama, key-key itu juga akan kedaluwarsa hampir bersamaan. Ini memicu stampede terjadwal. TTL jitter memecah momen kedaluwarsa dengan menambahkan variasi acak kecil pada TTL.

base_ttl = 300  # 5 menit
jitter = random_between(0, 60)
actual_ttl = base_ttl + jitter
cache.set(key, value, ttl=actual_ttl)

Mengapa ini efektif? Karena beban refresh tersebar di waktu yang berbeda, bukan menumpuk pada satu detik yang sama.

Kesalahan umum:

  • jitter terlalu kecil sehingga efeknya tidak terasa;
  • jitter terlalu besar sehingga data menjadi jauh lebih lama dari yang diharapkan;
  • semua key diberi TTL sama tanpa mempertimbangkan tingkat volatilitas data.

3. Terapkan single-flight locking

Pada saat cache miss, hanya satu request yang boleh membangun ulang data untuk key yang sama. Request lain tidak boleh semuanya menembak database. Ini biasa disebut single-flight, request coalescing, atau lock per key.

function getOrLoad(key):
  value = cache.get(key)
  if value exists:
    return value

  if lock.acquire("lock:" + key, timeout=5s):
    try:
      value = cache.get(key)
      if value exists:
        return value

      value = loadFromDatabaseOrUpstream(key)
      cache.set(key, value, ttl=ttlWithJitter())
      return value
    finally:
      lock.release("lock:" + key)
  else:
    stale = cache.getStale(key)
    if stale exists:
      return stale
    waitShort()
    retryOnceOrFailGracefully()

Poin pentingnya adalah double-check setelah lock didapat. Bisa saja request lain sudah lebih dulu mengisi cache tepat sebelum lock diperoleh.

Trade-off:

  • Lock terlalu lama dapat menambah latensi.
  • Lock yang salah implementasi dapat macet dan malah menciptakan bottleneck baru.
  • Untuk data sangat populer, fallback ke stale sering lebih aman daripada membuat banyak request menunggu lock.

4. Gunakan stale-while-revalidate

Stale-while-revalidate memungkinkan Anda mengembalikan data yang sedikit kedaluwarsa sambil memicu refresh di background. Ini sering menjadi kompromi terbaik saat traffic melonjak.

Contohnya, Anda bisa mendefinisikan dua jendela waktu:

  • fresh window: data dianggap segar;
  • stale window: data boleh disajikan sementara refresh dilakukan.
if cache_hit and age < fresh_ttl:
  return cached_value

if cache_hit and age < fresh_ttl + stale_ttl:
  trigger_background_refresh_once(key)
  return cached_value

return rebuild_with_single_flight(key)

Mengapa pendekatan ini sering lebih baik daripada memaksa konsistensi penuh? Karena pada burst traffic, availability biasanya lebih bernilai daripada kesegaran absolut untuk data yang tidak kritis, seperti halaman katalog, profil publik, atau agregasi statistik.

Namun untuk data sensitif seperti saldo, kuota, atau status transaksi, toleransi stale harus sangat hati-hati atau tidak dipakai sama sekali.

Mencegah queue banjir dan worker overload

1. Jangan mengubah semua masalah menjadi job async

Queue bukan lubang tanpa dasar. Saat traffic meledak, memindahkan pekerjaan ke queue hanya menggeser tekanan dari API ke worker. Jika laju enqueue lebih tinggi daripada kapasitas pemrosesan, backlog akan terus naik.

Sebelum enqueue job, tanyakan:

  • Apakah job ini benar-benar harus dibuat untuk setiap request?
  • Apakah beberapa job bisa digabung berdasarkan key yang sama?
  • Apakah hasilnya bisa dideduplikasi atau diabaikan jika masih ada job serupa yang pending?

Contoh yang sering berguna adalah coalescing job per entitas, misalnya hanya satu job refresh profil per user atau satu job rebuild cache per resource.

2. Terapkan rate limiting di depan jalur mahal

Rate limiting bukan hanya untuk mencegah abuse. Ini juga alat proteksi internal agar satu kelas request tidak menghabiskan seluruh kapasitas sistem.

Beberapa titik umum untuk rate limiting:

  • per IP atau token di API gateway;
  • per route mahal, misalnya endpoint pencarian atau export;
  • per tenant atau pelanggan agar satu tenant tidak mendominasi kapasitas;
  • per aksi enqueue job.

Ketika limit tercapai, respons yang lebih sehat adalah 429 Too Many Requests, respons degradasi, atau fallback ke data cache, bukan memaksa sistem menerima semua beban sampai runtuh.

3. Tambahkan backpressure yang nyata

Backpressure berarti produsen pekerjaan dipaksa melambat saat konsumen tidak mampu mengikuti. Tanpa backpressure, API akan terus mendorong job ke queue meski worker sudah penuh.

Bentuk backpressure yang praktis:

  • tolak enqueue saat queue depth melewati ambang tertentu;
  • kurangi concurrency request pada endpoint mahal;
  • ubah respons sinkron menjadi hasil parsial atau asynchronous acknowledgement;
  • nonaktifkan fitur sekunder saat mode proteksi aktif.

Backpressure bekerja karena menjaga sistem tetap di wilayah operasi yang dapat dipulihkan. Tujuannya bukan nol error, tetapi menghindari kegagalan total.

4. Batasi concurrency worker dengan sengaja

Kesalahan umum saat queue memanjang adalah menaikkan jumlah worker tanpa batas. Ini bisa mempercepat kerusakan jika bottleneck sebenarnya ada di database, cache, koneksi jaringan, atau API upstream.

Batasi concurrency berdasarkan resource yang benar-benar terbatas:

  • jumlah koneksi database yang aman;
  • throughput API upstream;
  • kapasitas CPU dan memori;
  • ukuran payload dan waktu proses rata-rata.

Jika job I/O-bound, concurrency bisa lebih tinggi. Jika job berat ke database atau CPU, concurrency perlu lebih konservatif.

5. Gunakan retry yang terlihat dan terkontrol

Retry berguna untuk kegagalan sementara, tetapi berbahaya jika semua jenis error di-retry otomatis. Ini bisa menciptakan retry storm.

Praktik yang lebih aman:

  • retry hanya untuk error transient, misalnya timeout atau 5xx upstream;
  • gunakan exponential backoff dengan jitter;
  • batasi jumlah retry;
  • bedakan retryable dan non-retryable error;
  • simpan alasan kegagalan yang terlihat di log dan metrik.
if error is transient:
  retry_delay = backoff(attempt) + random_jitter()
  requeue(job, delay=retry_delay)
else:
  send_to_dead_letter_queue(job, reason=error_code)

Visibilitas retry penting. Jika Anda hanya melihat queue length, Anda bisa salah paham: backlog tampak stabil padahal worker sibuk memproses job yang sama berulang kali.

6. Siapkan dead-letter queue

Dead-letter queue (DLQ) menampung job yang gagal berulang atau tidak valid. Tanpa DLQ, poison job dapat berputar terus dan menghabiskan kapasitas worker.

DLQ bermanfaat untuk:

  • mengisolasi job bermasalah;
  • menganalisis payload atau dependency yang gagal;
  • mencegah queue utama tersumbat oleh job yang tidak bisa selesai.

Kesalahan umum adalah memiliki DLQ tetapi tidak pernah dipantau. DLQ harus dianggap sebagai sinyal gangguan produksi, bukan tempat sampah permanen.

Idempotensi job: syarat mutlak saat retry tak terhindarkan

Dalam sistem queue, at-least-once delivery lebih umum daripada exactly-once. Artinya job yang sama bisa diproses lebih dari sekali. Karena itu job harus idempotent: menjalankannya dua kali tidak boleh menyebabkan efek samping ganda.

Teknik umum:

  • gunakan idempotency key berdasarkan operasi bisnis;
  • simpan status operasi yang sudah selesai;
  • gunakan constraint unik di database untuk mencegah duplikasi;
  • pisahkan langkah yang aman diulang dari langkah yang menyebabkan side effect eksternal.
function processJob(job):
  key = job.idempotency_key

  if alreadyProcessed(key):
    return success

  beginTransaction()
  try:
    performBusinessChange(job)
    markProcessed(key)
    commit()
  except:
    rollback()
    raise

Idempotensi tidak gratis. Anda menambah penyimpanan state, constraint, atau kompleksitas transaksi. Namun tanpa itu, retry saat gangguan akan menciptakan inkonsistensi yang jauh lebih mahal.

Consistency vs availability saat traffic meledak

Tidak semua data harus diperlakukan sama. Saat sistem berada di bawah tekanan, Anda perlu memutuskan di mana harus condong ke availability dan di mana harus menjaga consistency.

Kapan stale data dapat diterima

  • halaman publik;
  • konten katalog;
  • statistik agregat yang tidak kritis;
  • hasil rekomendasi yang tidak presisi mutlak.

Kapan consistency lebih penting

  • pembayaran dan status transaksi;
  • saldo, kuota, inventaris real-time;
  • otorisasi dan permission sensitif;
  • operasi yang memicu side effect eksternal permanen.

Kesalahan umum adalah memaksakan freshness penuh untuk semua endpoint, lalu heran mengapa sistem rapuh saat viral. Sebaliknya, membiarkan stale pada data kritis juga berbahaya. Strategi terbaik biasanya berbeda per domain data, bukan satu kebijakan global.

Metrik yang wajib dipantau

Anda tidak bisa mengendalikan burst jika hanya melihat CPU dan memori. Metrik berikut lebih langsung menggambarkan kesehatan sistem pada skenario stampede dan queue overload:

Metrik cache

  • cache hit ratio per endpoint atau per key class;
  • jumlah cache miss untuk key populer;
  • latensi rebuild cache;
  • jumlah lock acquisition sukses/gagal;
  • persentase respons stale yang disajikan.

Metrik queue dan worker

  • queue depth;
  • queue age atau waktu tunggu job tertua;
  • enqueue rate vs processing rate;
  • success rate, retry rate, failure rate;
  • DLQ inflow;
  • worker concurrency aktif;
  • waktu proses per jenis job.

Metrik dependency

  • latensi database dan jumlah koneksi aktif;
  • error rate upstream;
  • timeout rate;
  • throttling dari pihak ketiga.

Queue depth saja tidak cukup. Queue bisa terlihat stabil tetapi queue age meningkat, artinya job lama tertahan. Atau depth naik sedikit tetapi retry rate meledak, artinya kapasitas efektif turun drastis.

Failure mode yang sering terjadi

TTL seragam untuk semua key

Ini memicu gelombang refresh serentak. Solusinya: jitter dan segmentasi TTL berdasarkan karakter data.

Lock ada, tetapi fallback tidak ada

Request yang gagal mendapat lock akhirnya menunggu terlalu lama atau menembak ulang dependency. Solusinya: fallback ke stale, timeout pendek, dan respons degradasi.

Retry tanpa klasifikasi error

Error validasi, payload rusak, atau state bisnis ilegal tetap di-retry. Solusinya: pisahkan retryable dan non-retryable, lalu kirim sisanya ke DLQ.

Scale worker tanpa melihat bottleneck

Menambah worker justru menghabisi koneksi database atau membuat upstream makin penuh. Solusinya: ukur bottleneck aktual dan batasi concurrency pada titik sempit.

Semua request diberi prioritas sama

Traffic non-kritis bisa memakan kapasitas endpoint inti. Solusinya: prioritasi queue, rate limit per kelas trafik, dan mode degradasi untuk fitur sekunder.

Contoh kebijakan praktis yang masuk akal

Untuk endpoint baca yang populer:

  • aktifkan read-through cache;
  • TTL dasar 1-5 menit sesuai volatilitas data;
  • tambahkan jitter 10-20% dari TTL dasar;
  • gunakan single-flight per key saat miss;
  • sajikan stale selama masih aman secara bisnis;
  • batasi refresh background agar tidak duplikatif.

Untuk queue pekerjaan berat:

  • enqueue hanya jika benar-benar perlu;
  • deduplikasi job per resource penting;
  • batasi concurrency worker;
  • retry dengan exponential backoff dan jitter;
  • gunakan DLQ untuk poison job;
  • pastikan job idempotent.

Untuk operasi saat burst terdeteksi:

  • aktifkan rate limit lebih ketat pada endpoint mahal;
  • nonaktifkan fitur non-esensial yang memicu banyak job;
  • naikkan kapasitas hanya jika dependency inti mampu menahan beban tambahan;
  • prioritaskan request baca yang bisa dilayani dari cache.

Checklist operasional saat traffic mulai meledak

  1. Cek hit ratio cache dan lonjakan miss pada key populer.
  2. Pastikan lock refresh cache bekerja dan tidak macet.
  3. Lihat queue depth dan queue age, bukan salah satu saja.
  4. Bandingkan enqueue rate dengan processing rate worker.
  5. Periksa retry rate dan error yang paling dominan.
  6. Pastikan DLQ tidak mulai terisi oleh pola yang sama.
  7. Aktifkan rate limiting atau mode degradasi pada jalur mahal.
  8. Validasi bahwa worker tidak melebihi kapasitas database/upstream.
  9. Jika perlu, sajikan stale data untuk endpoint non-kritis.
  10. Catat key, route, atau job yang menjadi hotspot untuk perbaikan permanen.

Penutup

Mencegah stampede cache dan queue banjir saat traffic meledak bukan soal satu alat, melainkan soal mengatur siapa yang boleh memicu kerja mahal, kapan, dan sebanyak apa. Read-through cache, TTL jitter, single-flight locking, dan stale-while-revalidate mengurangi ledakan di jalur baca. Rate limiting, backpressure, DLQ, retry yang terkendali, dan idempotensi menjaga jalur async tetap sehat.

Jika harus memilih, utamakan desain yang fail soft: sebagian request boleh menerima stale, ditunda, atau ditolak secara jelas, asalkan sistem inti tetap hidup dan bisa pulih cepat. Dalam situasi burst yang dipicu momentum eksternal, kemampuan menahan lonjakan lebih penting daripada mengejar perilaku sempurna di semua jalur.