📚 Topik: Backpressure & Queue Semantics — At-Least-Once vs Exactly-Once d-backpressure · Distributed Systems · depth 3

🎯 Tujuan Belajar

Setelah sesi ini, keputusan berikut jadi lebih baik:

1. Kapan pakai queue dan kapan queue justru memindahkan masalah (dan memperburuknya).
2. Memilih semantik delivery yang benar per hop — dan tahu bahwa "exactly-once" di level end-to-end itu tidak ada; yang ada effectively-once lewat idempotensi.
3. Mendesain idempotency key dan dedup window yang tidak bocor di tepi.
4. Mengenali metastable failure: sistem yang sudah pulih kapasitasnya tapi tidak pulih throughput-nya.

🧠 Penjelasan Inti

Dua masalah berbeda, sering dicampur

Keduanya ketemu di satu titik: queue adalah buffer, dan buffer tanpa batas = bug yang tertunda.

Kenapa backpressure harus ada

Sistem punya kapasitas layanan (μ). Kalau arrival rate λ > μ, antrean tumbuh tanpa batas. Matematikanya tidak negotiable:

Little's Law: L = λ × W - λ = 100 rps, W = 200 ms → L = 20 request in-flight. Ini angka yang harus ditampung pool/thread/connection. - Balik: kalau concurrency dibatasi 20 dan latency 200 ms, throughput plafon = 100 rps. Concurrency limit adalah throughput limit.

M/M/1: L = ρ/(1-ρ), W = 1/(μ(1-ρ))

Konsekuensi arsitektural: latency bukan fungsi linear dari load. Di 90% utilisasi, sedikit lonjakan = latency 2×. Karena itu target utilisasi produksi biasanya 60–70%, bukan 90%. (Ini konsekuensi model antrean, bukan angka benchmark vendor — angka aktual tergantung distribusi arrival; arrival yang bursty/bukan Poisson lebih buruk lagi.)

Tiga strategi menghadapi overload — pilih salah satu, jangan diam

1. Buffer (antrean) — tunda kerja. Menangani spike, kalah pada sustained overload. Buffer wajib bounded.
2. Shed (drop/reject) — tolak lebih awal, murah. 429 + Retry-After, atau drop pesan non-kritis. Butuh definisi prioritas.
3. Degrade — kerjakan lebih murah: cache stale, skip enrichment, sampling, jawaban parsial.

Yang tidak boleh: buffer unbounded (OOM) atau retry tanpa batas (retry storm → amplifikasi beban 3–10× saat downstream sudah sekarat).

Mekanisme backpressure yang nyata

• Bounded queue + blocking/slowdown producer. Node stream: write() return false → berhenti sampai 'drain'. highWaterMark = ambang buffer.
• Credit-based / pull-based. Consumer minta N item; producer tidak boleh kirim lebih. AMQP basic.qos(prefetch), Kafka max.poll.records + pause()/resume(), gRPC flow control (HTTP/2 window).
• Semaphore / bulkhead. Batasi concurrency per dependency. Beda dari rate limit: rate limit = laju/waktu, semaphore = in-flight.
• Adaptive concurrency limit. Ukur latency (mis. p95) dan sesuaikan limit dengan AIMD atau gradient — lebih tahan terhadap downstream yang melambat dibanding limit statis. (Pendekatan yang dipopulerkan Netflix concurrency-limits; ini pola, bukan spesifikasi.)
• End-to-end signal. Backpressure harus merambat ke ujung. Kalau hop tengah punya queue, sinyal berhenti di situ dan producer hulu tidak pernah tahu. Ini sumber utama "sistem terlihat sehat, downstream sekarat".
• Load shedding di edge (gateway/LB) dengan admission control: tolak di pintu, bukan setelah 3 hop.

Semantik delivery — yang sebenarnya dijamin

Kenapa exactly-once delivery mustahil secara umum: ack dan proses adalah dua operasi pada dua sistem berbeda tanpa commit protokol bersama. Kalau consumer crash setelah proses tapi sebelum ack, sistem tidak bisa membedakan "sudah diproses" dari "belum" — harus pilih salah satu: kirim ulang (duplikat) atau jangan (hilang). Ini varian Two Generals; tidak ada jumlah handshake yang menyelesaikannya. Jadi semua "exactly-once" industri adalah exactly-once processing effect, bukan exactly-once delivery.

Kafka, spesifik (fakta, bukan klaim benchmark): - Idempotent producer (enable.idempotence=true, default aktif di client modern): broker menyimpan (producerId, partition, sequenceNumber) dan membuang duplikat retry dalam sesi producer. Ini menutup duplikat akibat retry internal producer — bukan duplikat akibat consumer crash. - Transaksi (transactional.id + sendOffsetsToTransaction): atomicitas tulis-ke-banyak-partisi plus commit offset consumer. Offset jadi bagian transaksi → hilangnya duplikat di pola read-process-write selama output juga Kafka dan consumer baca dengan isolation.level=read_committed. - Di luar batas itu (sink ke Postgres, HTTP call ke payment gateway), jaminan berhenti. Butuh idempotensi di sink.

Batas dedup yang harus eksplisit: - Dedup butuh state: store key + TTL. TTL = dedup window. Pesan yang di-retry setelah window lewat = diproses dua kali. Retry policy dan dedup window harus kompatibel (max retry delay × max attempts < window). - Dedup by key tidak menyelesaikan ordering. Butuh partisi per key agar urutan terjaga (Kafka: key → partition; konsekuensinya hot partition). - Natural idempotency > tabel dedup: UPDATE ... WHERE version = $expected, INSERT ... ON CONFLICT DO NOTHING, state machine dengan transisi legal (PENDING → PAID idempoten, PAID → PAID no-op).

⚙️ Cara Kerja Internal

Alur at-least-once yang benar (poll loop)

loop:
  batch = consumer.poll(max.poll.records=N, max.poll.interval.ms=M)
  try:
    result = process(batch)          # idempoten by design
    producer.send(outputs)           # atau tulis ke DB
    commit(offsets)                  # SETELAH sukses
  except Transient:
    retry with backoff (bounded)     # duplikat mungkin terjadi → aman karena idempoten
  except Poison:
    send to DLQ, commit offset       # jangan block partisi

Dua timer yang sering dilupakan: - max.poll.interval.ms — consumer dianggap mati kalau tidak poll dalam window ini → rebalance → partisi pindah → duplikat. Batch processing yang lambat memicu ini. Mitigasi: kurangi max.poll.records, proses async dengan batas, atau naikkan interval (trade-off: deteksi mati lebih lambat). - Rebalance = titik duplikat paling sering di Kafka. Cooperative rebalancing mengurangi stop-the-world, tidak menghapus duplikat.

Offset commit bukan ACK

Commit offset menyatakan "semua sebelum ini sudah diproses" — high-water mark, bukan per-pesan. Commit setelah N dari 100 pesan batch sukses = 100 pesan dianggap selesai. Kalau butuh granularitas, commit per-pesan (mahal) atau idempotensi per-pesan (murah).

Outbox pattern (menutup gap DB↔broker)

Masalah: tulis DB sukses, publish ke broker gagal → event hilang. Atau publish sukses, DB rollback → event hantu.

BEGIN
  INSERT INTO orders (...)
  INSERT INTO outbox (id, topic, payload, created_at)
COMMIT
-- relay terpisah (polling atau CDC/WAL) publish outbox → broker, tandai sent

Satu transaksi lokal = satu sumber kebenaran. Relay at-least-once → consumer wajib idempoten. Harga: latency tambahan + tabel outbox perlu di-prune.

Backpressure propagasi (rantai)

client → [LB: rate limit + shed 429] → [svc A: semaphore per dep] → [queue bounded] → [svc B: pull-based, prefetch=K]

Aturan: setiap hop punya batas, dan batas itu terlihat (metrik queue depth + in-flight + lag). Queue tanpa alarm = bug yang menunggu.

🏗️ Diagram: di mana backpressure mati

Producer ──► [queue TANPA BATAS] ──► Consumer (lambat)
                    │
                    └── producer tidak pernah merasa lambat
                        queue tumbuh → memory naik → GC pressure → latency naik
                        → consumer makin lambat → queue makin tumbuh  ☠

vs.

Producer ──► [queue bounded, size=N] ──► Consumer
                    │
                    ├─ penuh → producer block / 429 / drop-oldest
                    └─ sinyal balik ke hulu → hulu melambat atau shed

Perbedaan satu properti: batas. Bounded queue mengubah "kehilangan data diam-diam + OOM" menjadi "penolakan eksplisit" — yang bisa diobservasi dan diberi kebijakan.

⚖️ Trade-off & Kapan JANGAN Dipakai

Yang paling sering salah: menambah queue untuk "menyerap" overload. Queue menyerap spike, bukan defisit kapasitas. Kalau λ > μ secara persisten, queue hanya mengubah kapan kegagalan terjadi, bukan apakah.

Kapan JANGAN pakai exactly-once transaksional: kalau efek sampingnya keluar dari boundary transaksi (email, payment gateway, third-party API). Transaksi Kafka tidak bisa rollback HTTP call. Di situ idempotency key di sisi penerima adalah satu-satunya jawaban jujur.

🏭 Contoh Produksi & Failure Mode

Pola yang terbukti: backpressure yang benar terlihat di metrik, bukan di kode. Kalau kamu tidak bisa menjawab "berapa queue depth sekarang, berapa lag, berapa in-flight per dependency, berapa yang di-shed" — kamu belum punya backpressure, kamu punya harapan.

⚠️ Miskonsepsi Umum

1. "Kafka exactly-once, jadi sistem saya exactly-once." Jaminan berhenti di boundary Kafka. Sink non-Kafka = at-least-once + idempotensi milikmu.
2. "Idempotent producer = consumer aman dari duplikat." Tidak. Itu menutup duplikat retry producer. Duplikat consumer (crash setelah proses, sebelum commit) tetap terjadi.
3. "Tambah queue = tambah resilience." Queue tanpa batas = penundaan kegagalan. Queue tanpa consumer yang di-scale = akumulasi utang.
4. "At-least-once itu jelek, kita butuh exactly-once." At-least-once + idempotensi = effectively-once, lebih murah, lebih sederhana, dan bekerja lintas sistem. Exactly-once transaksional mahal dan rapuh di tepi.
5. "Retry bikin sistem lebih tahan gagal." Retry tanpa batas + tanpa jitter = amplifier kegagalan. Retry adalah kredit, bukan hak.
6. "Autoscaling menyelesaikan overload." Kalau bottleneck di DB atau di dependency bersama, menambah app instance hanya menambah tekanan.
7. "Latency tinggi berarti butuh lebih banyak worker." Kalau λ sudah > μ, lebih banyak worker membantu; kalau λ < μ tapi latency tinggi, masalahnya di antrean/blocking/contention — tambah worker bisa memperburuk (context switch, lock contention, connection pool exhaustion).

✅ Cek Pemahaman

1. Consumer Kafka memproses 500 pesan per batch, commit setelah batch selesai. Di pesan ke-300 prosesnya lambat (60s), max.poll.interval.ms=300000. Crash terjadi di pesan ke-450. Berapa pesan yang diproses ulang, dan perubahan konfigurasi mana yang mengurangi jumlah duplikat tanpa mengorbankan throughput secara berlebihan?
2. Sistem punya target 200 rps, latency p95 50 ms. Berapa concurrency minimum yang dibutuhkan (Little's Law)? Kalau utilisasi naik ke 90%, apa yang terjadi pada p95 dan berapa concurrency efektif yang perlu disiapkan?
3. Kamu menulis event ke Postgres lalu publish ke Kafka. Publish gagal setelah commit DB. Sebutkan dua solusi dan trade-off masing-masing — dan jelaskan mengapa "publish dulu, lalu commit DB" bukan solusi.

🔑 Poin Kunci

• Bounded everywhere. Setiap buffer harus punya batas dan alarm. Tanpa batas, backpressure tidak ada — hanya penundaan.
• Little's Law mengikat concurrency, throughput, dan latency. Ketiganya tidak bisa diinginkan sekaligus.
• Latency meledak non-linear mendekati saturasi. Target utilisasi 60–70%, bukan 90%.
• Exactly-once delivery mustahil; effectively-once processing dicapai lewat idempotensi. Itu default yang benar.
• Idempotensi lebih murah daripada koordinasi. Pilih operasi yang idempoten secara natural (upsert, conditional write, state machine) sebelum membangun tabel dedup.
• Dedup window harus cocok dengan retry policy — kalau tidak, jaminannya bocor diam-diam.
• Backpressure harus merambat end-to-end. Queue di tengah memutus sinyal.
• Retry adalah anggaran terbatas, bukan refleks. Backoff + jitter + retry budget + circuit breaker.
• Metastable failure nyata: pemulihan butuh shedding, bukan kesabaran.
• Observability dulu: queue depth, consumer lag, in-flight, shed rate, dedup hit rate. Tanpa itu, semua di atas teori.

➡️ Eksplorasi Lanjut

1. Outbox + CDC — bandingkan polling relay vs Debezium/WAL tailing: latency, beban DB, kompleksitas operasional.
2. Saga vs 2PC — kenapa saga menukar atomicity dengan kompensasi, dan kapan kompensasi tidak mungkin (efek eksternal ireversibel).
3. Idempotency key di HTTP API — desain header, scope key, retry semantics (Idempotency-Key + cached response), dan interaksi dengan 409/422.
4. CoDel & adaptive concurrency — load shedding berbasis sojourn time, bukan queue length; kenapa lebih tahan terhadap bufferbloat.
5. Backpressure di runtime — Go channel buffer + errgroup.SetLimit, Node stream highWaterMark/pipeline, Rust tokio bounded mpsc, actor mailbox bounded. Bandingkan default-nya: mana yang default-nya unbounded dan kenapa itu jebakan.
6. Ordering vs parallelism — partitioning per key, hot partition, dan kapan harus menyerah pada global ordering.