<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Reliability on Nalar</title>
    <link>https://nalar.dev/id/tags/reliability/</link>
    <description>Recent content in Reliability on Nalar</description>
    <generator>Hugo</generator>
    <language>id-id</language>
    <lastBuildDate>Sun, 20 Sep 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://nalar.dev/id/tags/reliability/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Backpressure Mengikat Kecepatan Producer pada Kapasitas Consumer</title>
      <link>https://nalar.dev/id/backpressure-mengikat-kecepatan-producer-pada-kapasitas-consumer/</link>
      <pubDate>Sun, 20 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/backpressure-mengikat-kecepatan-producer-pada-kapasitas-consumer/</guid>
      <description>&lt;p&gt;Producer yang cepat dan consumer yang lebih lambat dapat berjalan aman hanya selama selisih laju keduanya tetap terbatas. Jika pekerjaan masuk lebih cepat daripada kemampuan penyelesaiannya dalam waktu yang cukup lama, buffering tidak menghapus overload. Buffer hanya menyimpan selisih tersebut.&lt;/p&gt;&#xA;&lt;p&gt;Backpressure menjadikan ketimpangan kapasitas itu bagian dari protokol antarkomponen. Alih-alih menerima pekerjaan tanpa batas, stage yang jenuh membuat kode upstream melambat, menunggu kapasitas, mengurangi demand, atau menolak pekerjaan berdasarkan kebijakan yang eksplisit.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Bulkhead Mengisolasi Resource Pool Sebelum Kegagalan Menyebar</title>
      <link>https://nalar.dev/id/bulkhead-mengisolasi-resource-pool-sebelum-kegagalan-menyebar/</link>
      <pubDate>Sun, 20 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/bulkhead-mengisolasi-resource-pool-sebelum-kegagalan-menyebar/</guid>
      <description>&lt;p&gt;Sebuah service dapat tetap sehat pada level proses tetapi menjadi tidak berguna karena satu workload menghabiskan seluruh resource eksekusi yang langka. Dependency yang lambat dapat menahan semua outbound connection. Tenant yang sangat aktif dapat memenuhi setiap worker slot. Background job dapat mengambil semaphore permit yang sama dengan request interaktif.&lt;/p&gt;&#xA;&lt;p&gt;Isolasi bulkhead membatasi keterkaitan tersebut. Alih-alih membiarkan pekerjaan yang tidak berkaitan berebut satu pool tanpa pembagian, sistem mempartisi resource tertentu dan memberi setiap kelas pekerjaan bagian yang terbatas. Saturasi kemudian memiliki blast radius yang lebih kecil.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Idempotency Key Membuat Retry Write Aman Diulang</title>
      <link>https://nalar.dev/id/idempotency-key-membuat-retry-write-aman-diulang/</link>
      <pubDate>Sun, 20 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/idempotency-key-membuat-retry-write-aman-diulang/</guid>
      <description>&lt;h1 id=&#34;idempotency-key-membuat-retry-write-aman-diulang&#34;&gt;Idempotency Key Membuat Retry Write Aman Diulang&lt;/h1&gt;&#xA;&lt;p&gt;Client dapat kehilangan response dari write yang sebenarnya sudah berhasil. Koneksi mungkin terputus setelah server mencatat pembayaran, membuat order, atau menjadwalkan job, tetapi sebelum response sampai ke caller. Dari sisi client, kegagalan dan keberhasilan dapat terlihat sama.&lt;/p&gt;&#xA;&lt;p&gt;Retry tanpa kontrol berbahaya untuk operasi dengan efek non-idempotent. Mengirim &lt;code&gt;POST&lt;/code&gt; yang sama dua kali dapat membuat dua resource atau mengenakan charge dua kali. Tidak melakukan retry juga menyisakan outcome yang ambigu bagi caller.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Load Shedding Melindungi Pekerjaan Berguna Saat Kapasitas Habis</title>
      <link>https://nalar.dev/id/load-shedding-melindungi-pekerjaan-berguna-saat-kapasitas-habis/</link>
      <pubDate>Sun, 20 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/load-shedding-melindungi-pekerjaan-berguna-saat-kapasitas-habis/</guid>
      <description>&lt;p&gt;Sebuah service dapat berjalan sehat pada 2.000 request per detik lalu runtuh pada 2.400. Tambahan 400 request tidak sekadar menunggu giliran. Request tersebut dapat memenuhi connection slot, antrean, memory, worker thread, database session, dan retry budget sementara throughput yang berguna justru turun.&lt;/p&gt;&#xA;&lt;p&gt;Load shedding menempatkan keputusan admission sebelum resource langka terpakai penuh. Ketika sistem tidak mampu melayani seluruh pekerjaan masuk di dalam batas operasinya, sebagian request ditolak lebih awal daripada membiarkan semuanya berebut resource sampai seluruh jalur menjadi lambat.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Propagasi Deadline Menghentikan Request Kedaluwarsa Menghabiskan Kapasitas Downstream</title>
      <link>https://nalar.dev/id/propagasi-deadline-menghentikan-request-kedaluwarsa-menghabiskan-kapasitas-downstream/</link>
      <pubDate>Sun, 20 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/propagasi-deadline-menghentikan-request-kedaluwarsa-menghabiskan-kapasitas-downstream/</guid>
      <description>&lt;p&gt;Timeout yang hanya dipasang di tepi luar request tidak otomatis membatasi pekerjaan yang dimulai lebih dalam pada call graph. Client dapat berhenti menunggu setelah 800 milidetik, sementara service internal masih menjalankan query database, remote call, atau queued task selama beberapa detik berikutnya. Responsnya sudah tidak berguna bagi client tersebut, tetapi sistem masih menghabiskan kapasitas untuk memprosesnya.&lt;/p&gt;&#xA;&lt;p&gt;Propagasi deadline membawa batas waktu request bersama pekerjaannya. Setiap komponen dapat membandingkan batas tersebut dengan waktu saat ini, menyisihkan waktu untuk pemrosesan lokal, lalu menolak atau membatalkan pekerjaan yang sudah tidak muat. Hasilnya bukan sekadar kegagalan yang lebih cepat. Konsumsi resource menjadi lebih erat dengan pekerjaan yang masih berguna.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Token Bucket Memisahkan Laju Berkelanjutan dari Kapasitas Burst</title>
      <link>https://nalar.dev/id/token-bucket-memisahkan-laju-berkelanjutan-dari-kapasitas-burst/</link>
      <pubDate>Sun, 20 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/token-bucket-memisahkan-laju-berkelanjutan-dari-kapasitas-burst/</guid>
      <description>&lt;p&gt;Rate limit yang hanya dinyatakan sebagai “100 request per detik” masih menyisakan satu kebijakan penting. Apakah client boleh mengirim 100 request tepat pada awal setiap detik, atau request tersebut harus tersebar merata? Token bucket membuat batas ini eksplisit dengan memisahkan laju berkelanjutan dari kapasitas burst.&lt;/p&gt;&#xA;&lt;p&gt;Limiter menyimpan saldo token sampai kapasitas tertentu. Token bertambah sesuai refill rate yang dikonfigurasi. Sebuah operasi diterima hanya jika token yang tersedia mencukupi, lalu biaya operasi dikurangkan dari saldo. Waktu idle mengumpulkan kapasitas untuk burst berikutnya, tetapi tidak pernah melewati batas bucket.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
