Rekayasa Perangkat Lunak

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 / 23 Sep 2026 / 5 min read

Hazard Pointer Menunda Reklamasi sampai Reader Melepas Referensi

Menghapus node dari struktur data lock-free tidak membuat memorinya langsung aman untuk digunakan kembali. Thread lain mungkin sudah memegang alamat node tersebut dan masih akan mengaksesnya. Jika thread penghapus membebaskan alokasi terlalu cepat, pembaruan atomik yang benar dapat diikuti use-after-free. Hazard pointer memisahkan penghapusan logis dari reklamasi fisik. Reader memublikasikan alamat yang hendak diakses ke hazard slot yang ditentukan. Thread lain dapat melepas node dari struktur dan menaruhnya pada retired list, tetapi reklamasi menunggu sampai pemindaian memastikan tidak ada hazard slot yang melindungi alamat itu.

Rekayasa Perangkat Lunak 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

Tombstone Mencegah Data Terhapus Muncul Kembali

Tombstone Mencegah Data Terhapus Muncul Kembali Penghapusan bukan sekadar ketiadaan nilai dalam replicated store. Ketiadaan tidak membawa informasi apakah sebuah key sengaja dihapus atau sebuah replica memang belum pernah menerimanya. Ketika replica dapat terputus sementara, perbedaan ini menentukan apakah sinkronisasi mempertahankan penghapusan atau justru mengembalikan data lama. Tombstone mencatat penghapusan sebagai state berversi. Replica dapat membandingkan marker tersebut dengan nilai lama dan mempertahankan penghapusan saat rekonsiliasi. Marker akhirnya dapat dibuang, tetapi hanya setelah sistem memiliki batas yang kuat bahwa nilai lama tidak dapat kembali.

Rekayasa Perangkat Lunak Sistem Terdistribusi

Rekayasa Perangkat Lunak / 22 Sep 2026 / 6 min read

Request Sequence Guard Menolak Response UI yang Terlambat

Request Sequence Guard Menolak Response UI yang Terlambat Interface interaktif sering mengirim request baru sebelum request sebelumnya selesai. Search box, filter, perubahan route, autocomplete, dan detail panel dapat menghasilkan pola ini. Urutan selesainya operasi jaringan tidak dijamin sama dengan urutan perubahan state oleh pengguna. Perbedaan urutan tersebut dapat menghasilkan race yang halus. Request A dimulai lebih dahulu, request B dimulai setelahnya, B selesai lebih cepat, lalu interface merender B. Jika A kemudian selesai dan callback miliknya menulis tanpa memeriksa konteks, layar kembali ke data yang terkait dengan intent lama.

Rekayasa Perangkat Lunak Frontend

Rekayasa Perangkat Lunak / 22 Sep 2026 / 6 min read

Request Coalescing Mencegah Cache Miss Melipatgandakan Beban Backend

Request Coalescing Mencegah Cache Miss Melipatgandakan Beban Backend Cache miss biasanya murah ketika satu caller memicu satu lookup ke backend. Miss yang sama dapat menjadi mahal ketika banyak caller datang untuk key yang sama dalam waktu hampir bersamaan. Setiap caller melihat key belum tersedia, masing-masing memulai pekerjaan identik, lalu backend menerima lonjakan justru ketika cache tidak memberi perlindungan untuk key tersebut. Request coalescing mengubah pola concurrency itu. Caller pertama menjadi leader untuk sebuah key. Caller berikutnya bergabung dengan operasi yang sedang berjalan dan menunggu hasilnya, bukan memulai pekerjaan setara. Setelah fill selesai, hasilnya dapat mengisi cache sekaligus dikembalikan kepada caller yang menunggu.

Rekayasa Perangkat Lunak Caching

Rekayasa Perangkat Lunak / 22 Sep 2026 / 6 min read

Rendezvous Hashing Membatasi Perpindahan Key saat Membership Berubah

Rendezvous Hashing Membatasi Perpindahan Key saat Membership Berubah Aturan partisi memiliki dua tugas yang dapat saling tarik-menarik. Key perlu tersebar di antara node yang tersedia, tetapi sebagian besar key juga sebaiknya tetap di tempatnya ketika kumpulan node berubah. Aturan modulo sederhana menangani tugas pertama dengan baik pada cluster yang stabil, tetapi buruk untuk tugas kedua. Rendezvous hashing, yang juga disebut highest-random-weight hashing, memberi score deterministik kepada setiap pasangan key dan node yang eligible. Node dengan score tertinggi menjadi pemilik key. Penambahan atau penghapusan node hanya mengubah perbandingan yang melibatkan member tersebut, sehingga key dengan pemenang yang tidak terpengaruh tetap pada penempatannya.

Rekayasa Perangkat Lunak Sistem Terdistribusi

Rekayasa Perangkat Lunak / 22 Sep 2026 / 7 min read

Optimistic Concurrency Menolak Write Stale Sebelum Mengganti State yang Lebih Baru

Optimistic Concurrency Menolak Write Stale Sebelum Mengganti State yang Lebih Baru Alur read-modify-write terlihat sederhana ketika hanya satu actor menyentuh sebuah record. Client membaca state, mengubah sebagian isinya, lalu menulis hasilnya kembali. Saat beberapa actor bekerja bersamaan, jeda antara read dan write menjadi race. Writer lain dapat melakukan commit terhadap nilai yang lebih baru pada jeda tersebut, lalu update tanpa kondisi dapat menghapusnya. Optimistic concurrency control menambahkan kondisi pada write terakhir. Client membawa version yang berasal dari state yang dibacanya, dan storage layer menerima mutation hanya jika version itu masih current. Ketidakcocokan menjadi conflict, bukan overwrite yang tidak terlihat.

Rekayasa Perangkat Lunak Concurrency

Rekayasa Perangkat Lunak / 22 Sep 2026 / 6 min read

Optimistic Concurrency Control Menolak Write dari State yang Sudah Usang

Optimistic Concurrency Control Menolak Write dari State yang Sudah Usang Dua client dapat membaca record yang sama, membuat perubahan berbeda, lalu menyimpan dengan selisih beberapa detik. Jika setiap update langsung mengganti value yang tersimpan, write terakhir dapat menghapus perubahan sebelumnya meski kedua request sama-sama dinyatakan berhasil. Optimistic concurrency control mencegah overwrite diam-diam dengan memberi syarat pada write. Client menyimpan version saat membaca data. Update hanya berhasil jika version tersebut masih berlaku. Version yang sudah berubah membuat write berakhir sebagai conflict, bukan kehilangan perubahan tanpa tanda.

Rekayasa Perangkat Lunak Concurrency

Rekayasa Perangkat Lunak / 22 Sep 2026 / 5 min read

Load Shedding Melindungi Layanan Saat Kapasitas Habis

Load Shedding Melindungi Layanan Saat Kapasitas Habis Sebuah layanan dapat menerima pekerjaan lebih banyak daripada yang mampu diselesaikannya. Gejala pertama sering bukan error langsung, melainkan antrean yang terus tumbuh sementara seluruh worker sibuk. Request menunggu lebih lama, deadline habis, client melakukan retry, dan traffic retry tambahan dapat memperparah overload. Load shedding menempatkan titik penolakan eksplisit sebelum spiral tersebut menghabiskan resource yang tersedia. Layanan menerima pekerjaan yang masih sesuai kapasitas operasional dan menggagalkan kelebihannya dengan cepat agar throughput berguna tetap tersedia bagi request yang masih dapat selesai.

Rekayasa Perangkat Lunak Reliability

Rekayasa Perangkat Lunak / 22 Sep 2026 / 6 min read

Kompensasi Saga Bukan Transaction Rollback

Kompensasi Saga Bukan Transaction Rollback Operasi yang melibatkan banyak service dapat melewati inventory, payment, shipping, dan sistem lain yang melakukan commit secara independen. Setelah satu service melakukan commit, kegagalan pada step berikutnya tidak dapat membuat commit sebelumnya hilang melalui database rollback biasa. Saga menangani boundary ini dengan memasangkan forward action dengan recovery action yang eksplisit. Jika step berikutnya gagal, coordinator menjalankan kompensasi untuk step sebelumnya yang sudah selesai ketika business process mengizinkannya.

Rekayasa Perangkat Lunak Sistem Terdistribusi

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

Fencing Token Memblokir Pemegang Lock yang Sudah Kedaluwarsa

Fencing Token Memblokir Pemegang Lock yang Sudah Kedaluwarsa Distributed lock sering dipakai agar dua worker tidak mengubah resource yang sama pada saat bersamaan. Kasus yang lebih sulit muncul ketika kepemilikan lock bergantung pada lease. Sebuah client dapat memperoleh lease, berhenti cukup lama sampai lease kedaluwarsa, lalu melanjutkan eksekusi setelah client lain memperoleh lease baru. Dari sisi client lama, eksekusi hanya sempat terhenti. Dari sisi layanan koordinasi, kepemilikan sudah berpindah. Jika sistem penyimpanan yang dilindungi menerima write dari keduanya, pemegang lama dapat menimpa pekerjaan yang dilakukan pemegang saat ini.

Rekayasa Perangkat Lunak Sistem Terdistribusi

Rekayasa Perangkat Lunak / 22 Sep 2026 / 6 min read

Dead-Letter Queue Mengisolasi Poison Message Tanpa Menghambat Progres

Dead-Letter Queue Mengisolasi Poison Message Tanpa Menghambat Progres Message consumer biasanya memperlakukan kegagalan sebagai kondisi sementara pada percobaan awal. Database mungkin tidak tersedia, remote service dapat timeout, atau worker dapat restart di antara penerimaan dan acknowledgment message. Retry tepat digunakan ketika percobaan berikutnya memiliki peluang masuk akal untuk berhasil. Sebagian message gagal karena sebab yang berbeda. Payload-nya rusak, entity yang dirujuk tidak akan pernah memenuhi kondisi wajib, atau consumer memiliki defect deterministik yang dipicu input tersebut. Delivery berulang kemudian menghabiskan kapasitas tanpa membawa message lebih dekat ke penyelesaian. Dead-letter queue memberi kegagalan itu tujuan terpisah setelah kebijakan retry normal habis.

Rekayasa Perangkat Lunak Messaging

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

Bulkhead Mengisolasi Concurrency Sebelum Satu Dependency Menghabiskannya

Bulkhead Mengisolasi Concurrency Sebelum Satu Dependency Menghabiskannya Sebuah service dapat memiliki CPU dan memori yang cukup tetapi berhenti membuat progres berguna karena concurrency habis. Thread, koneksi database, outbound socket, worker slot, dan permit request in-flight bersifat finite. Jika satu dependency melambat, call menuju dependency tersebut dapat memenuhi seluruh shared pool. Bulkhead isolation membagi kapasitas itu sebelum saturation terjadi. Workload yang dapat gagal secara independen memperoleh anggaran concurrency terpisah, sehingga tekanan pada satu jalur tidak otomatis memakai setiap slot yang diperlukan jalur lain.

Rekayasa Perangkat Lunak Reliability

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 / 22 Sep 2026 / 5 min read

Backpressure Mencegah Producer Cepat Membanjiri Consumer Lambat

Backpressure Mencegah Producer Cepat Membanjiri Consumer Lambat Pipeline stabil selama pekerjaan meninggalkan setiap tahap dengan laju yang kurang lebih seimbang dengan laju masuk dalam rentang waktu yang relevan. Ketika producer dapat mengirim pekerjaan lebih cepat daripada kemampuan consumer menyelesaikannya, selisih tersebut harus menumpuk di suatu tempat. Antrean tanpa batas membuat penumpukan itu mudah tersembunyi. Request terus diterima, producer tampak sehat, dan consumer tetap bekerja. Sementara itu, pekerjaan dalam antrean memakai memori dan semakin tua sebelum dieksekusi. Backpressure mengubah saturation downstream menjadi sinyal upstream sebelum backlog berubah menjadi kegagalan.

Rekayasa Perangkat Lunak Backpressure