Rekayasa Perangkat Lunak

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

Rekayasa Perangkat Lunak / 21 Sep 2026 / 7 min read

Write Skew Merusak Invariant pada Snapshot Isolation

Write Skew Merusak Invariant pada Snapshot Isolation Snapshot isolation memberi setiap transaksi tampilan stabil atas data yang sudah commit. Properti ini menghilangkan banyak anomali akibat nilai yang berubah di tengah transaksi. Namun, properti tersebut tidak otomatis membuat setiap eksekusi concurrent setara dengan suatu urutan serial. Write skew memperlihatkan celah itu dengan jelas. Dua transaksi membaca state valid yang sama, mengambil keputusan dari state tersebut, lalu menulis row yang berbeda. Karena write set keduanya tidak beririsan, kedua commit dapat berhasil meski hasil gabungannya melanggar aturan yang tetap dipenuhi oleh masing-masing transaksi saat berdiri sendiri.

Rekayasa Perangkat Lunak Database

Rekayasa Perangkat Lunak / 21 Sep 2026 / 5 min read

Write Skew Dapat Merusak Invariant Lintas Baris pada Snapshot Isolation

Write Skew Dapat Merusak Invariant Lintas Baris pada Snapshot Isolation Snapshot isolation memberi setiap transaksi view database yang stabil dan umumnya mencegah transaksi concurrent melakukan commit atas write yang saling bertabrakan pada baris yang sama. Properti concurrency ini kuat, tetapi tidak membuat setiap invariant aplikasi menjadi serializable. Write skew muncul ketika dua transaksi membaca state yang saling beririsan, mengambil keputusan dari snapshot valid yang sama, lalu menulis record yang berbeda. Karena write set keduanya tidak bertabrakan, kedua commit dapat berhasil. State gabungannya dapat melanggar aturan yang sudah diperiksa masing-masing transaksi sebelum menulis.

Rekayasa Perangkat Lunak Database

Rekayasa Perangkat Lunak / 21 Sep 2026 / 6 min read

Version Vector Memisahkan Kausalitas dari Concurrency

Version Vector Memisahkan Kausalitas dari Concurrency Data yang direplikasi dapat menerima write di beberapa node ketika komunikasi antar-node sedang terlambat. Saat dua versi bertemu kemudian, store perlu menentukan apakah satu versi merupakan turunan versi lain atau keduanya dibuat secara independen. Wall-clock timestamp memberi urutan yang tampak total, tetapi clock order bukan causal order. Dua replica dapat melakukan write selama partition, dan timestamp yang kebetulan lebih besar tidak membuat write tersebut menjadi turunan write lainnya.

Rekayasa Perangkat Lunak Sistem Terdistribusi

Rekayasa Perangkat Lunak / 21 Sep 2026 / 4 min read

Version Vector Membedakan Update Concurrent dari Penerus Kausal

Version Vector Membedakan Update Concurrent dari Penerus Kausal Data tereplikasi dapat menerima write pada node berbeda ketika komunikasi antar-node tertunda. Saat versi-versi tersebut bertemu kembali, scalar revision number dapat menunjukkan bahwa dua nilai berbeda, tetapi tidak selalu dapat menentukan apakah satu versi merupakan turunan versi lain atau keduanya dibuat secara independen. Version vector mencatat progres per-replica. Perbandingan counter tersebut menghasilkan partial order: satu versi dapat mendominasi versi lain, kedua vector dapat sama, atau tidak ada yang mendominasi. Kondisi terakhir menandai history concurrent yang membutuhkan aturan rekonsiliasi eksplisit.

Rekayasa Perangkat Lunak Sistem Terdistribusi

Rekayasa Perangkat Lunak / 21 Sep 2026 / 7 min read

Transactional Outbox Menutup Celah Dual-Write

Transactional Outbox Menutup Celah Dual-Write Sebuah service sering perlu mengubah state di database dan memublikasikan event untuk satu request. Kedua operasi itu tampak berdekatan di kode aplikasi, tetapi melewati boundary durability yang berbeda. Commit database dapat berhasil saat publish ke broker gagal, atau publish dapat berhasil sebelum transaksi database mengalami rollback. Pemisahan tersebut menghasilkan masalah dual-write. Mengubah urutan dua write independen tidak dapat membuat keduanya atomic dengan sendirinya. Pola transactional outbox mengubah boundary itu. Request menulis data bisnis dan record outbox dalam transaksi database lokal yang sama. Relay terpisah kemudian memublikasikan record outbox yang sudah commit ke broker. Publikasi menjadi asynchronous, tetapi intent yang durable untuk melakukan publish ikut commit bersama state yang memicunya.

Rekayasa Perangkat Lunak Sistem Terdistribusi

Rekayasa Perangkat Lunak / 21 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 di database sekaligus memublikasikan message dalam satu request. Kedua aksi itu dapat terlihat berdekatan di application code, tetapi masing-masing memiliki commit boundary sendiri. Jika database dan broker tidak berbagi transaction protocol, dua write biasa tidak dapat dibuat atomic hanya dengan mengatur urutannya. Bayangkan order service menyimpan order yang diterima lalu mengirim OrderCreated. Publish setelah database commit menyisakan celah crash sebelum pemanggilan broker. Publish lebih dulu menghasilkan celah sebaliknya: consumer dapat menerima event untuk state yang akhirnya gagal commit.

Rekayasa Perangkat Lunak Sistem Terdistribusi

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

Request Coalescing Meredam Lonjakan Cache Miss

Request Coalescing Meredam Lonjakan Cache Miss Cache miss biasanya murah ketika satu caller memicu satu backend read. Miss yang sama dapat menjadi mahal ketika ratusan caller datang untuk key yang sama sebelum fill pertama selesai. Setiap caller melihat cache kosong lalu memulai work yang setara, sehingga load berlipat tepat ketika cached value sedang tidak tersedia. Request coalescing menempatkan concurrency boundary kecil di sekitar fill tersebut. Caller pertama memulai operasi backend. Caller berikutnya untuk key yang sama bergabung dengan operasi yang sedang berjalan, bukan memulai operasi baru. Setelah selesai, hasilnya dapat mengisi cache sekaligus dikirim ke caller yang menunggu.

Rekayasa Perangkat Lunak Caching

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

Propagasi Deadline Menjaga Budget Timeout Antar-RPC Hop

Propagasi Deadline Menjaga Budget Timeout Antar-RPC Hop Timeout yang dimulai ulang pada setiap boundary service dapat mengubah budget caller yang singkat menjadi rangkaian work yang jauh lebih lama. Client mungkin memberi waktu 800 milidetik, service A menghabiskan 500 milidetik untuk proses lokal, lalu memanggil service B dengan timeout baru sebesar 800 milidetik. B dapat terus bekerja lama setelah client berhenti menunggu. Propagasi deadline mempertahankan satu waktu akhir pada request. Setiap hop menghitung sisa budget dari deadline tersebut dan tidak memulai work yang tidak lagi muat di dalamnya. Mekanisme ini tidak otomatis membuat eksekusi lebih cepat. Hasil utamanya adalah eksekusi terbatas yang mematuhi kontrak waktu dari upstream.

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