Software Engineering

Rekayasa Perangkat Lunak / 23 Sep 2026 / 5 min read

Priority Inheritance Membatasi Priority Inversion di Sekitar Mutex

Priority Inheritance Membatasi Priority Inversion di Sekitar Mutex Priority scheduling tidak menjamin task runnable dengan priority tertinggi selalu dapat maju. Task ber-priority tinggi dapat terblokir pada mutex yang dimiliki task ber-priority rendah. Jika pekerjaan ber-priority menengah kemudian melakukan preemption terhadap pemilik mutex, task ber-priority tinggi tetap terblokir walaupun pekerjaan menengah itu tidak memiliki dependency langsung terhadap mutex. Kondisi ini disebut priority inversion. Inversion dimulai dari dependency biasa: task ber-priority tinggi memerlukan resource yang sedang dimiliki task ber-priority rendah. Bagian yang merugikan adalah interference dari task di antara kedua priority tersebut, karena interference itu dapat menunda pemilik mutex dan memperpanjang interval blocking.

Software Engineering Concurrency

Rekayasa Perangkat Lunak / 23 Sep 2026 / 5 min read

Lock Convoy Mengubah Critical Section Singkat Menjadi Antrean Panjang

Lock Convoy Mengubah Critical Section Singkat Menjadi Antrean Panjang Mutex dapat melindungi critical section yang sangat kecil dan tetap menjadi pusat masalah latensi yang besar. Kode di dalam lock mungkin hanya memerlukan beberapa mikrodetik pada kondisi normal, tetapi satu holder yang tertunda dapat membuat beberapa thread menumpuk di belakangnya. Setelah antrean terbentuk, lock dapat terus berada dalam kondisi contention ketika ownership berpindah dari satu thread yang menunggu ke thread berikutnya.

Software Engineering Concurrency

Rekayasa Perangkat Lunak / 22 Sep 2026 / 6 min read

Write Skew Dapat Merusak Invarian pada Snapshot Isolation

Write Skew Dapat Merusak Invarian pada Snapshot Isolation Snapshot isolation memberi setiap transaction pandangan stabil terhadap data yang sudah commit dan biasanya menolak update konkuren pada row yang sama. Kombinasi ini menghilangkan banyak anomali yang muncul pada isolation level yang lebih lemah. Namun, tidak setiap invarian aplikasi otomatis menjadi serializable. Write skew adalah kasus penting. Dua transaction membaca state yang saling beririsan, mengambil keputusan dari snapshot valid yang sama, lalu mengubah row yang berbeda. Karena write set keduanya tidak bertabrakan, keduanya dapat commit. Hasil gabungannya dapat melanggar aturan yang tetap terpenuhi pada snapshot masing-masing transaction.

Software Engineering Database

Rekayasa Perangkat Lunak / 22 Sep 2026 / 5 min read

Transactional Outbox Menutup Celah Commit antara Database dan Broker

Transactional Outbox Menutup Celah Commit antara Database dan Broker Sebuah service sering perlu mengubah state database sekaligus mengirim message. Order dapat berubah menjadi confirmed sementara event OrderConfirmed dikirim ke broker. Kedua tindakan tersebut menyentuh sistem terpisah, sehingga dua write biasa tidak dapat membentuk satu commit atomik kecuali kedua sistem ikut dalam distributed transaction. Bagian berbahaya berada pada interval di antara kedua write. Commit database lebih dahulu membuat process dapat gagal sebelum publish. Publish lebih dahulu membuat commit database dapat gagal sesudahnya. Membalik urutan hanya memindahkan failure window, bukan menghapusnya.

Software Engineering Distributed Systems

Rekayasa Perangkat Lunak / 22 Sep 2026 / 5 min read

Idempotency Key Menyatukan Retry sebagai Satu Operasi Logis

Idempotency Key Menyatukan Retry sebagai Satu Operasi Logis Client dapat kehilangan response dari request yang sebenarnya berhasil. Server mungkin sudah melakukan commit untuk charge, membuat order, atau memasukkan job ke queue, lalu koneksi gagal sebelum response mencapai caller. Dari sisi client, hasil operasi menjadi ambigu. Retry diperlukan untuk availability, tetapi retry biasa dapat mengulangi side effect. Idempotency key memberi cara bagi client untuk menyatakan bahwa beberapa percobaan HTTP mewakili satu operasi logis.

Software Engineering API

Rekayasa Perangkat Lunak / 22 Sep 2026 / 7 min read

Hedged Request Menukar Kerja Duplikat dengan Tail Latency yang Lebih Rendah

Hedged Request Menukar Kerja Duplikat dengan Tail Latency yang Lebih Rendah Sebagian besar request dapat selesai cepat sementara sebagian kecil memerlukan waktu jauh lebih lama. Worker yang sibuk, antrean jaringan sesaat, cache entry yang dingin, garbage collection, storage contention, atau gangguan lokal lain dapat membuat satu attempt jauh melampaui median. Pada skala besar, outlier tersebut terlihat pada latency p95, p99, dan persentil yang lebih tinggi meski rata-rata service time tetap sehat.

Software Engineering Distributed Systems

Rekayasa Perangkat Lunak / 22 Sep 2026 / 6 min read

Fencing Token Menghentikan Pemegang Lease yang Sudah Stale

Fencing Token Menghentikan Pemegang Lease yang Sudah Stale Distributed lease memberi satu worker izin sementara untuk bertindak sebagai owner. Lease akhirnya kedaluwarsa agar worker lain dapat mengambil alih setelah crash atau gangguan jaringan. Mekanisme itu menjaga availability, tetapi expiry saja tidak menjamin worker lama sudah berhenti. Sebuah process dapat pause cukup lama hingga lease kedaluwarsa, lalu kembali berjalan dengan local state yang sudah stale. Garbage-collection pause yang panjang, scheduler stall, virtual machine yang disuspend, atau network path yang tertunda dapat menciptakan kondisi ini. Jika worker lama melakukan write setelah pengganti mengambil ownership, dua worker dapat memengaruhi resource yang sama meskipun lease service tidak pernah menganggap kedua lease valid pada saat yang sama.

Software Engineering Distributed Systems

Rekayasa Perangkat Lunak / 22 Sep 2026 / 6 min read

Consistent Hashing Membatasi Perpindahan Key Saat Topologi Berubah

Consistent Hashing Membatasi Perpindahan Key Saat Topologi Berubah Distributed cache atau service yang dipartisi memerlukan aturan untuk memetakan setiap key ke node. Aturan sederhana seperti hash(key) % N menarik selama jumlah node tetap. Masalah muncul ketika N berubah. Perubahan dari empat node menjadi lima mengganti pembagi untuk setiap key. Sebagian besar remainder ikut berubah, sehingga penambahan kapasitas biasa dapat memetakan ulang bagian besar dataset sekaligus. Pada cache, kondisi ini dapat memicu gelombang miss. Pada storage yang menyimpan state, perubahan tersebut dapat menghasilkan pekerjaan migrasi yang besar.

Software Engineering Distributed Systems

Rekayasa Perangkat Lunak / 22 Sep 2026 / 7 min read

Circuit Breaker Menghentikan Panggilan Berulang ke Dependency yang Gagal

Circuit Breaker Menghentikan Panggilan Berulang ke Dependency yang Gagal Dependency yang sudah gagal dapat menghabiskan kapasitas caller lebih besar daripada dependency yang sehat. Request menunggu timeout, retry menambah traffic, connection pool tetap terisi, dan slot worker tertahan oleh pekerjaan yang kecil kemungkinannya selesai. Circuit breaker menempatkan gate yang memiliki state di depan dependency agar caller dapat berhenti mengirim panggilan setelah bukti kegagalan mencapai batas yang dikonfigurasi. Gate ini bukan pengganti timeout, retry, atau capacity limit. Fungsinya mengoordinasikan panggilan berulang dalam aliran request. Ketika dependency terlihat tidak sehat, breaker menggagalkan panggilan baru secara lokal selama suatu periode, alih-alih terus meminta sistem remote membuktikan kegagalan yang sama.

Software Engineering Distributed Systems

Rekayasa Perangkat Lunak / 22 Sep 2026 / 6 min read

Bulkhead Mencegah Satu Dependency yang Jenuh Menghabiskan Semua Worker

Bulkhead Mencegah Satu Dependency yang Jenuh Menghabiskan Semua Worker Sebuah service dapat memiliki CPU yang sehat, memory yang masih tersedia, dan internal code yang responsif tetapi tetap menjadi unavailable. Satu downstream dependency cukup untuk menghabiskan seluruh concurrency budget jika call ke sana melambat dan setiap request dibiarkan menunggu. Dampaknya tidak berhenti pada dependency yang lambat. Worker pool, connection pool, semaphore, queue, dan request slot yang dipakai bersama dapat mengubah saturasi lokal menjadi outage di seluruh service. Bulkhead isolation membatasi blast radius tersebut dengan menyediakan kapasitas terpisah untuk workload atau dependency yang berbeda.

Software Engineering Distributed Systems

Rekayasa Perangkat Lunak / 22 Sep 2026 / 7 min read

Bounded Queue Mengubah Overload Menjadi Keputusan Admission yang Eksplisit

Bounded Queue Mengubah Overload Menjadi Keputusan Admission yang Eksplisit Queue menyerap perbedaan singkat antara laju kedatangan dan laju pemrosesan. Buffer ini berguna ketika lonjakan berakhir sebelum worker tertinggal terlalu jauh. Mekanisme yang sama menjadi berbahaya ketika pekerjaan terus datang lebih cepat daripada pekerjaan selesai: setiap item yang diterima menambah waktu tunggu dan memakai kombinasi memori, descriptor, reference, atau storage persisten. Bounded queue menetapkan batas tetap pada jumlah pekerjaan yang menunggu. Ketika batas tercapai, sistem harus mengambil keputusan admission alih-alih terus memperpanjang backlog. Bergantung pada interface, keputusan itu dapat berupa memblokir producer, menolak pekerjaan baru, membuang pekerjaan tertentu, atau mengalihkannya ke domain kapasitas lain.

Software Engineering Distributed Systems

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 / 6 min read

Transactional Outbox Menjaga State Database dan Event Tetap Selaras

Sebuah service sering perlu mengubah state database sekaligus menerbitkan event dalam satu operasi. Sebuah order dapat berpindah ke status paid sementara OrderPaid harus sampai ke message broker. Kedua penulisan itu melewati sistem berbeda, sehingga transaksi database biasa tidak dapat membuat kedua commit menjadi atomik. Menulis ke database lebih dahulu menyisakan celah: proses dapat berhenti setelah commit tetapi sebelum event diterbitkan. Menerbitkan event lebih dahulu menciptakan celah sebaliknya: consumer dapat menerima event untuk perubahan database yang kemudian gagal.

Software Engineering Transactional Outbox

Rekayasa Perangkat Lunak / 20 Sep 2026 / 5 min read

Token Bucket Memisahkan Laju Berkelanjutan dari Kapasitas Burst

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. 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.

Software Engineering Rate Limiting

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 / 4 min read

Request Coalescing Menggabungkan Cache Miss yang Terjadi Bersamaan

Request Coalescing Menggabungkan Cache Miss yang Terjadi Bersamaan Cache miss dapat menjadi mahal ketika banyak request meminta key yang sama pada waktu hampir bersamaan. Tanpa koordinasi, setiap caller dapat memulai query database, remote call, atau komputasi yang identik. Cache akhirnya terisi, tetapi backend menerima burst tepat ketika nilai cache sedang tidak tersedia. Request coalescing mengubah batas concurrency tersebut. Caller pertama memulai load dan menerbitkan in-flight entry untuk key itu. Caller berikutnya bergabung ke entry tersebut alih-alih memulai pekerjaan ekuivalen. Setelah load selesai, hasilnya dibagikan kepada caller yang menunggu lalu in-flight entry dihapus.

Software Engineering Caching

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 / 6 min read

Propagasi Deadline Menghentikan Request Kedaluwarsa Menghabiskan Kapasitas Downstream

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. 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.

Software Engineering Deadline

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

Power of Two Choices Mengurangi Ketimpangan Load dengan Dua Sampel

Power of Two Choices Mengurangi Ketimpangan Load dengan Dua Sampel Load balancer yang memilih satu destination secara acak memiliki biaya kecil dan mudah didesentralisasi, tetapi penempatan acak dapat menghasilkan queue yang tidak merata. Pada sisi lain, memilih destination dengan load terendah dari seluruh pool membutuhkan informasi load terbaru untuk setiap kandidat dan dapat membuat load balancer sendiri menjadi mahal. Strategi power of two choices berada di antara kedua desain tersebut. Untuk setiap request, ambil dua destination yang memenuhi syarat, bandingkan sinyal load, lalu kirim request ke kandidat yang lebih baik. Dua observasi cukup untuk menghindari banyak penempatan buruk tanpa memerlukan pencarian global.

Software Engineering Load Balancing

Rekayasa Perangkat Lunak / 20 Sep 2026 / 6 min read

Load Shedding Melindungi Pekerjaan Berguna Saat Kapasitas Habis

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. 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.

Software Engineering Load Shedding

Rekayasa Perangkat Lunak / 20 Sep 2026 / 7 min read

Idempotency Key Membuat Retry Command Tetap Aman

Client dapat kehilangan response sebuah command meskipun server sudah menyelesaikan operasinya. Koneksi bisa terputus setelah pembayaran tercatat, job dibuat, atau order diterima. Dari sisi client, timeout tidak menunjukkan apakah command gagal sebelum dieksekusi atau berhasil sebelum response hilang. Retry diperlukan untuk availability, tetapi mengulang command yang mengubah state dapat menggandakan side effect. Idempotency key memberi identitas yang sama pada seluruh percobaan untuk satu command logis. Server menyimpan hasil yang terkait dengan identitas tersebut dan menggunakannya kembali ketika command yang sama datang lagi.

Software Engineering Idempotency

Rekayasa Perangkat Lunak / 20 Sep 2026 / 5 min read

Hedged Request Menukar Kerja Tambahan dengan Tail Latency yang Lebih Rendah

Sebuah service dapat memiliki median latency yang sehat tetapi sesekali menghasilkan request yang jauh lebih lambat daripada request lain. Queueing, replica yang lambat, connection setup, garbage collection, storage stall, atau gangguan network sementara dapat menahan satu attempt sementara kapasitas ekuivalen di jalur lain masih tersedia. Hedged request membatasi paparan terhadap satu jalur lambat tersebut. Client memulai satu attempt seperti biasa. Jika attempt itu masih pending setelah jeda yang ditentukan, client dapat memulai attempt ekuivalen kedua. Hasil layak pertama dipakai, lalu attempt yang tersisa dibatalkan jika cancellation didukung.

Software Engineering Sistem Terdistribusi

Rekayasa Perangkat Lunak / 20 Sep 2026 / 6 min read

Fencing Token Memblokir Pemegang Lock Lama di Resource

Fencing Token Memblokir Pemegang Lock Lama di Resource Lease terdistribusi dapat berakhir saat pemegangnya masih berjalan. Proses bisa berhenti sementara karena garbage collection, kehilangan kontak dengan coordinator, tertahan scheduler, atau aktif kembali setelah mesin mengalami suspend. Lock service dapat memberikan lease kepada worker lain secara sah sementara worker lama masih memiliki pekerjaan yang belum selesai. Celah ini menjadi penting ketika kedua worker masih dapat mencapai resource yang dilindungi. Lease mengatur kepemilikan di coordinator; lease tidak otomatis mencabut koneksi database, request storage, atau RPC tertunda yang disiapkan pemegang sebelumnya.

Software Engineering Sistem Terdistribusi