Reliabilitas

Rekayasa Perangkat Lunak / 21 Sep 2026 / 6 min read

Token Bucket Menjaga Kapasitas Burst Tanpa Menghapus Batas Rate

Token Bucket Menjaga Kapasitas Burst Tanpa Menghapus Batas Rate Batas requests-per-second yang kaku memperlakukan lonjakan singkat dan banjir traffic berkelanjutan sebagai kejadian yang sama. Pendekatan itu dapat terlalu ketat untuk service dengan caller yang secara alami mengirim request dalam kelompok. Token bucket memisahkan dua batas: admission rate jangka panjang dan jumlah burst traffic yang bersedia diserap service. Model ini memiliki dua parameter. Kapasitas bucket B adalah jumlah token maksimum yang dapat terkumpul. Refill rate r menambahkan token per satuan waktu hingga mencapai B. Sebuah request memakai token sesuai cost yang dikonfigurasi. Jika token mencukupi, request diteruskan; jika tidak, request ditolak, ditunda, atau ditangani oleh policy eksplisit lain.

Rekayasa Perangkat Lunak Sistem Terdistribusi

Rekayasa Perangkat Lunak / 21 Sep 2026 / 5 min read

Propagasi Deadline Menjaga Budget Waktu Request

Propagasi Deadline Menjaga Budget Waktu Request Sebuah request dapat melewati beberapa service sebelum menghasilkan response. Setiap hop mungkin memiliki queue, network call, retry policy, dan timeout lokal sendiri. Jika batas tersebut ditentukan secara independen, total request path dapat berjalan jauh lebih lama daripada waktu yang bersedia ditunggu caller. Propagasi deadline memberi seluruh path satu boundary waktu. Caller awal mengirim absolute deadline, atau time budget yang dikonversi menjadi deadline. Setiap komponen downstream memakai interval yang tersisa alih-alih memulai timeout baru dari nol.

Rekayasa Perangkat Lunak Sistem Terdistribusi

Rekayasa Perangkat Lunak / 21 Sep 2026 / 6 min read

Load Shedding Menjaga Pekerjaan Berguna Saat Saturasi

Load Shedding Menjaga Pekerjaan Berguna Saat Saturasi Sebuah service memiliki kapasitas terbatas untuk menyelesaikan pekerjaan per satuan waktu. Ketika beban yang masuk melewati kapasitas tersebut, menerima setiap request tidak menambah kapasitas. Keputusan itu justru menambah waktu tunggu, memakai memory dan connection slot, memperpanjang deadline, serta dapat membiarkan pekerjaan mahal terus berjalan setelah caller berhenti menunggu. Load shedding membuat admission menjadi eksplisit. Pekerjaan yang tidak dapat diproses service dalam operating envelope-nya ditolak lebih awal agar pekerjaan yang diterima tetap memiliki peluang realistis untuk selesai.

Rekayasa Perangkat Lunak Sistem Terdistribusi

Rekayasa Perangkat Lunak / 21 Sep 2026 / 6 min read

Idempotency Key Membatasi Mutasi Duplikat Saat Retry

Idempotency Key Membatasi Mutasi Duplikat Saat Retry Client dapat kehilangan respons dari mutasi yang sebenarnya berhasil. Server mungkin sudah melakukan commit untuk pembayaran, reservasi, atau submission job, lalu koneksi terputus sebelum respons mencapai caller. Dari sisi client, timeout tidak menunjukkan apakah mutasi gagal sebelum commit atau berhasil sebelum respons hilang. Retry diperlukan untuk menjaga availability, tetapi retry tanpa proteksi dapat mengulang side effect. Idempotency key memberi identitas stabil pada kedua attempt sehingga server dapat memperlakukannya sebagai satu operasi logis.

Rekayasa Perangkat Lunak Sistem Terdistribusi

Rekayasa Perangkat Lunak / 21 Sep 2026 / 7 min read

Hedged Request Memangkas Tail Latency dengan Duplikasi Terkendali

Hedged Request Memangkas Tail Latency dengan Duplikasi Terkendali Sebuah service dapat memiliki median latency yang sehat sementara sebagian kecil request membutuhkan waktu jauh lebih lama. Queueing, garbage collection, storage stall, packet loss, noisy neighbor, atau load replica yang tidak merata dapat memperpanjang bagian lambat dari distribusi. Pada request yang melakukan fan-out ke beberapa dependency, satu cabang lambat dapat mendominasi waktu respons keseluruhan. Hedged request mengurangi paparan tersebut dengan memulai salinan kedua setelah delay singkat. Kedua salinan diarahkan ke jalur eksekusi yang independen jika memungkinkan, lalu respons valid pertama yang selesai dipakai.

Rekayasa Perangkat Lunak Sistem Terdistribusi

Rekayasa Perangkat Lunak / 21 Sep 2026 / 6 min read

Batas Concurrency Adaptif Mengikuti Kapasitas Service yang Tersedia

Batas Concurrency Adaptif Mengikuti Kapasitas Service yang Tersedia Batas concurrency tetap mudah dioperasikan ketika kapasitas service stabil. Sistem nyata jarang berada dalam satu kondisi operasi. Contention database, cache hit rate, campuran request, latency downstream, ketersediaan CPU, dan perubahan deployment dapat menggeser jumlah pekerjaan yang mampu ditangani service secara bersamaan. Kontrol concurrency adaptif memperlakukan batas in-flight sebagai variabel kontrol. Limiter menerima pekerjaan sampai ceiling saat ini, mengamati perilaku service, lalu menyesuaikan ceiling tersebut. Sasarannya bukan concurrency maksimum, melainkan concurrency yang cukup untuk memakai kapasitas tersedia tanpa membiarkan antrean tumbuh jauh melewati area operasi yang berguna.

Rekayasa Perangkat Lunak Sistem Terdistribusi

Rekayasa Perangkat Lunak / 21 Sep 2026 / 6 min read

Backpressure Membatasi Pekerjaan Saat Consumer Tertinggal

Backpressure Membatasi Pekerjaan Saat Consumer Tertinggal Producer yang cepat dan consumer yang lebih lambat dapat berjalan bersama selama burst singkat jika buffer menyerap selisihnya. Susunan yang sama menjadi tidak stabil ketika perbedaan rate bertahan. Pekerjaan tertunda menumpuk, penggunaan memory naik, latency memanjang, dan item dapat kedaluwarsa sebelum sempat diproses consumer. Backpressure mengubah kontrak antara kedua sisi. Alih-alih menerima pekerjaan tanpa memperhatikan kondisi downstream, sistem mengekspos kapasitas terbatas kepada producer. Ketika kapasitas itu habis, produksi berhenti sementara, admission ditolak, atau policy overload eksplisit lain mulai berlaku.

Rekayasa Perangkat Lunak Sistem Terdistribusi

Rekayasa Perangkat Lunak / 20 Sep 2026 / 6 min read

Visibility Timeout Mengubah Delivery Pesan Menjadi Lease yang Dapat Diperpanjang

Consumer queue sering memerlukan waktu untuk menyelesaikan pekerjaan sebelum pesan aman untuk di-acknowledge. Menghapus pesan saat diterima membuat crash pada consumer berpotensi menghilangkan pekerjaan. Membiarkannya langsung tersedia membuat beberapa consumer dapat memproses item yang sama secara bersamaan. Visibility timeout mengambil posisi di antara kedua pilihan tersebut. Saat pesan diterima, pesan menjadi tidak tersedia sementara bagi consumer lain. Consumer memperoleh interval terbatas untuk menyelesaikan pekerjaan dan mengirim acknowledgement. Jika interval habis lebih dahulu, queue dapat membuka pesan untuk delivery berikutnya.

Software Engineering Message Queue

Rekayasa Perangkat Lunak / 20 Sep 2026 / 5 min read

Stale-While-Revalidate Mengeluarkan Refresh Cache dari Request Path

Stale-While-Revalidate Mengeluarkan Refresh Cache dari Request Path Cache entry tidak langsung kehilangan seluruh kegunaannya tepat saat freshness timer habis. Untuk sebagian data, value yang berumur beberapa detik tetap lebih berguna daripada membuat setiap caller menunggu backend refresh. Stale-while-revalidate memakai toleransi tersebut secara eksplisit: cache dapat menyajikan value yang sudah expired selama interval terbatas sementara refresh berjalan terpisah. Policy ini mengubah refresh dari kewajiban di request path menjadi background work untuk entry yang masih dapat diterima saat stale. Latency spike di sekitar expiration dapat berkurang, tetapi service harus memiliki batas jelas mengenai umur maksimum response yang masih boleh disajikan.

Software Engineering Caching

Rekayasa Perangkat Lunak / 20 Sep 2026 / 5 min read

Renewal Lease Memerlukan Margin Aman Sebelum Kedaluwarsa

Renewal Lease Memerlukan Margin Aman Sebelum Kedaluwarsa Lease memberi holder otoritas sementara sampai waktu kedaluwarsa yang tercatat. Otoritas itu harus diperpanjang melalui renewal sebelum batas waktunya. Menjadwalkan renewal tepat pada batas tersebut tidak menyisakan ruang untuk delay jaringan, jeda scheduler, latency storage, atau retry sementara. Desain yang lebih aman mencoba renewal lebih awal. Interval antara renewal yang direncanakan dan kedaluwarsa menjadi margin aman: waktu yang disediakan untuk ketidakpastian normal sebelum lease dianggap hilang.

Rekayasa Perangkat Lunak Sistem Terdistribusi

Rekayasa Perangkat Lunak / 20 Sep 2026 / 7 min read

Queue Terbatas Mengubah Overload Menjadi Penolakan Eksplisit

Queue Terbatas Mengubah Overload Menjadi Penolakan Eksplisit Queue dapat menyerap lonjakan singkat ketika request datang lebih cepat daripada kemampuan worker menyelesaikannya. Buffer tersebut berguna selama tetap berfungsi sebagai buffer. Jika producer terus dapat menambahkan pekerjaan tanpa batas tetap, overload berkepanjangan mengubah queue menjadi tumpukan request yang dapat menunggu lama setelah hasilnya tidak lagi berguna. Queue terbatas mengubah bentuk kegagalan itu. Queue menerima pekerjaan yang menunggu sampai kapasitas yang ditetapkan, lalu menolak admission tambahan sampai tersedia ruang. Service tetap mengalami overload, tetapi overload muncul sebagai keputusan kontrol yang eksplisit, bukan pertumbuhan memory dan waktu tunggu tanpa batas.

Software Engineering Reliabilitas

Rekayasa Perangkat Lunak / 20 Sep 2026 / 7 min read

Propagasi Deadline Menghentikan Pekerjaan Setelah Caller Menyerah

Propagasi Deadline Menghentikan Pekerjaan Setelah Caller Menyerah Timeout di edge tidak otomatis menghentikan pekerjaan yang berjalan lebih dalam di sistem. Client dapat meninggalkan request setelah dua detik sementara API server masih menunggu service lain, dan service tersebut mungkin masih menjalankan query database. Response sudah kehilangan penerimanya, tetapi CPU time, connection, memory, posisi queue, dan kapasitas downstream dapat tetap terpakai. Propagasi deadline membawa budget waktu milik caller melewati batas-batas tersebut. Setiap komponen menerima deadline absolut atau remaining budget yang setara, menolak pekerjaan yang tidak sempat dimulai, dan membatalkan operasi saat budget habis. Tujuannya bukan sekadar membuat kegagalan terjadi lebih cepat. Mekanisme ini mencegah pekerjaan tanpa guna hidup lebih lama daripada request yang menjadi alasan pekerjaan itu ada.

Software Engineering Sistem Terdistribusi

Rekayasa Perangkat Lunak / 20 Sep 2026 / 5 min read

Hedged Request Menekan Tail Latency dengan Biaya Terkendali

Hedged Request Menekan Tail Latency dengan Biaya Terkendali Sebuah service dapat memiliki median latency yang baik tetapi tetap menghasilkan sebagian kecil response yang sangat lambat. Antrean, jeda runtime, contention pada storage, packet loss, atau replica yang sedang sibuk dapat membuat request tertentu jauh lebih lambat daripada kasus umum. Hedged request menangani ekor distribusi tersebut dengan mengirim salinan kedua setelah request pertama tertahan selama jeda tertentu. Caller menerima response valid pertama lalu membatalkan attempt yang tersisa. Teknik ini menukar sejumlah pekerjaan tambahan yang dibatasi dengan peluang untuk keluar dari jalur eksekusi yang kebetulan lambat.

Rekayasa Perangkat Lunak Sistem Terdistribusi

Rekayasa Perangkat Lunak / 20 Sep 2026 / 5 min read

Bulkhead Mengisolasi Concurrency Antar-Dependency

Bulkhead Mengisolasi Concurrency Antar-Dependency Sebuah service dapat memiliki CPU yang masih longgar tetapi tetap tidak tersedia karena satu dependency berhenti menyelesaikan pekerjaan. Request yang menunggu database, remote API, atau storage service yang lambat tetap menahan slot eksekusi, connection, memory, dan posisi queue. Jika operasi yang tidak berkaitan memakai finite pool yang sama, satu jalur yang jenuh dapat menghabiskan kapasitas yang dibutuhkan jalur sehat. Isolasi bulkhead membagi concurrency bersama itu menjadi budget yang eksplisit. Panggilan ke satu dependency atau kelas workload memakai bounded pool yang tidak dapat dihabiskan kelas lain. Pola ini tidak memperbaiki dependency yang gagal. Fungsinya membatasi kapasitas lokal yang dapat ditempati kegagalan tersebut.

Software Engineering Concurrency

Teknologi / 16 Sep 2026 / 5 min read

TCP TIME-WAIT Mempertahankan State Koneksi yang Sudah Ditutup

Endpoint TCP dapat menyelesaikan operasi close dari aplikasi sementara protocol masih mempertahankan state untuk koneksi tersebut. Setelah active close menyelesaikan pertukaran FIN, endpoint biasanya masuk ke TIME-WAIT alih-alih langsung membuang connection record. State yang dipertahankan ini memiliki dua fungsi. Pertama, endpoint tetap dapat mengakui retransmitted final FIN. Kedua, ia memisahkan koneksi yang sudah ditutup dari incarnation berikutnya yang mungkin memakai local dan remote address serta port yang sama. Karena itu TIME-WAIT bukan established connection yang sedang idle. Ia adalah protocol boundary di antara connection incarnation.

TCP Jaringan