Rekayasa Perangkat Lunak

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

Rekayasa Perangkat Lunak / 21 Sep 2026 / 4 min read

Kolom Versi Mengubah Lost Update Menjadi Konflik yang Terdeteksi

Kolom Versi Mengubah Lost Update Menjadi Konflik yang Terdeteksi Alur read-modify-write dapat menimpa perubahan lain yang sudah commit walaupun setiap statement database berhasil. Dua client membaca row yang sama, menghitung replacement berbeda, lalu menulis secara berurutan. Tanpa kondisi yang mengikat setiap write ke state yang dibacanya, write terakhir dapat menghapus perubahan sebelumnya tanpa sinyal konflik. Kolom versi membuat dependency tersebut eksplisit. Client membaca data beserta versinya, lalu melakukan update hanya jika versi di storage masih sama dengan yang diamati. Perubahan versi mengubah race menjadi conditional update yang gagal, bukan lost update.

Rekayasa Perangkat Lunak Database

Rekayasa Perangkat Lunak / 21 Sep 2026 / 6 min read

Idempotency Key Membuat Retry Mutasi Tetap Aman

Idempotency Key Membuat Retry Mutasi Tetap Aman Client dapat kehilangan hasil mutasi yang sukses tanpa kehilangan mutasinya. Server mungkin sudah melakukan commit untuk pembayaran, reservasi, atau pengiriman job lalu koneksi terputus sebelum response sampai ke caller. Dari sisi client, timeout menyisakan dua kemungkinan: operasi gagal sebelum commit, atau commit sudah terjadi dan hanya response yang hilang. Retry secara buta pada mutasi non-idempotent dapat menerapkan efek dua kali. Menolak setiap retry membuat caller tidak memiliki jalur pemulihan dari hasil yang ambigu. Idempotency key memberi identitas stabil untuk satu operasi logis, sehingga percobaan berulang dapat memakai hasil dari percobaan pertama yang diterima alih-alih membuat efek baru.

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

Hedged Request Memangkas Tail Latency dengan Biaya Kapasitas

Hedged Request Memangkas Tail Latency dengan Biaya Kapasitas Sebuah service dapat memiliki median latency yang baik sementara sebagian kecil request memerlukan waktu jauh lebih lama. Queueing, cache dingin, runtime pause, packet loss sementara, atau operasi storage yang lambat dapat membuat satu percobaan tertinggal jauh dari jalur normal. Pada fan-out yang cukup besar, delay yang jarang itu menjadi umum pada batas request agregat. Hedged request memulai percobaan ekuivalen kedua setelah percobaan pertama belum selesai selama jeda yang ditentukan. Caller menerima hasil berguna pertama lalu membatalkan atau mengabaikan percobaan lainnya.

Rekayasa Perangkat Lunak Sistem Terdistribusi

Rekayasa Perangkat Lunak / 21 Sep 2026 / 6 min read

Fencing Token Menghentikan Write dari Pemegang Lease yang Sudah Stale

Fencing Token Menghentikan Write dari Pemegang Lease yang Sudah Stale Distributed lease dapat menentukan client yang saat ini memiliki sebuah resource, tetapi lease yang kedaluwarsa tidak langsung menghentikan pemegang sebelumnya. Sebuah process dapat pause, kehilangan akses network, atau macet cukup lama sampai lease-nya habis. Client lain kemudian memperoleh lease. Jika process lama kembali berjalan dan masih memiliki akses ke storage atau service yang dilindungi, kedua client dapat mengirim write. Lease manager sudah memindahkan ownership, tetapi resource yang dilindungi tidak memiliki dasar untuk membedakan holder saat ini dari holder yang stale. Fencing token menutup celah tersebut dengan menyertakan nomor generation yang terurut pada setiap acquisition yang berhasil. Resource hanya menerima operasi ketika token-nya setidaknya sama baru dengan token terbesar yang pernah diterima.

Rekayasa Perangkat Lunak Sistem Terdistribusi

Rekayasa Perangkat Lunak / 21 Sep 2026 / 6 min read

Consistent Hashing Membatasi Perpindahan Key Saat Membership Berubah

Consistent Hashing Membatasi Perpindahan Key Saat Membership Berubah Partisi hash sederhana sering tampak memadai: owner = hash(key) % node_count Dengan empat node, setiap key masuk ke salah satu dari empat remainder. Masalah muncul saat membership berubah. Peralihan dari empat node menjadi lima mengubah modulus, sehingga sebagian besar key memilih owner berbeda meski hanya satu node yang ditambahkan.

Rekayasa Perangkat Lunak Sistem Terdistribusi

Rekayasa Perangkat Lunak / 21 Sep 2026 / 6 min read

Circuit Breaker Membatasi Panggilan ke Dependency yang Bermasalah

Circuit Breaker Membatasi Panggilan ke Dependency yang Bermasalah Dependency remote dapat mengalami kegagalan yang menetap sekaligus mahal. Koneksi mencapai timeout, worker slot tetap terpakai, request queue membesar, dan retry menambah traffic ke service yang sedang tidak mampu merespons. Caller yang terus mengirim kelas request yang sama dapat mengubah satu kegagalan dependency menjadi tekanan pada process miliknya sendiri. Circuit breaker menempatkan keputusan admission yang memiliki state di depan panggilan tersebut. Selama dependency beroperasi dalam batas policy, panggilan diteruskan. Setelah kegagalan yang memenuhi kriteria melewati ambang, breaker menjadi open dan menolak panggilan baru secara lokal selama periode tertentu. Pemulihan diuji dengan traffic terbatas, bukan dengan langsung mengembalikan seluruh load normal.

Rekayasa Perangkat Lunak Sistem Terdistribusi

Rekayasa Perangkat Lunak / 21 Sep 2026 / 6 min read

Circuit Breaker Membatasi Kegagalan Berantai

Circuit Breaker Membatasi Kegagalan Berantai Dependency yang lambat atau gagal dapat menghabiskan kapasitas di luar komponen itu sendiri. Caller menunggu, melakukan retry, menahan socket, memakai worker slot, dan mempertahankan memory selama request belum selesai. Saat tekanan merambat ke upstream, gangguan lokal dapat berubah menjadi saturasi pada seluruh service. Circuit breaker menempatkan gate berstate di sekitar call menuju dependency tersebut. Breaker mengamati outcome, masuk ke state open ketika kebijakan failure terpenuhi, menolak call selama periode tertentu, lalu mengizinkan sejumlah kecil probe. Probe yang berhasil dapat mengembalikan breaker ke traffic normal; probe yang gagal mengembalikannya ke state open.

Rekayasa Perangkat Lunak Sistem Terdistribusi

Rekayasa Perangkat Lunak / 21 Sep 2026 / 6 min read

Bulkhead Mengisolasi Concurrency Antar-Failure Domain

Bulkhead Mengisolasi Concurrency Antar-Failure Domain Sebuah service dapat tetap dapat diakses ketika kapasitas bergunanya sudah habis. Dependency yang lambat menahan request, request tersebut memakai worker atau connection slot, lalu traffic lain menunggu di belakang pekerjaan yang tidak dapat segera selesai. Fault bermula pada satu jalur, tetapi resource pool bersama membuatnya menghabiskan kapasitas yang dibutuhkan semua jalur. Isolasi bulkhead membagi kapasitas terbatas tersebut. Call yang terkait dengan satu failure domain memperoleh bagian yang dibatasi, bukan bersaing tanpa pemisahan untuk seluruh pool. Ketika satu partisi penuh, admission gagal atau menunggu di dalam partisi itu sementara kapasitas untuk pekerjaan lain tetap tersedia.

Rekayasa Perangkat Lunak Sistem Terdistribusi

Rekayasa Perangkat Lunak / 21 Sep 2026 / 5 min read

Bounded Queue Mengubah Overload Menjadi Backpressure yang Eksplisit

Bounded Queue Mengubah Overload Menjadi Backpressure yang Eksplisit Queue dapat menyerap perbedaan singkat antara arrival rate dan processing rate. Buffer semacam ini berguna ketika lonjakan hanya berlangsung sementara. Risikonya muncul saat queue tidak memiliki batas yang bermakna: overload berkepanjangan tidak terlihat sebagai kegagalan admission, melainkan sebagai backlog yang terus tumbuh, konsumsi memori yang meningkat, dan request yang selesai setelah latency budget-nya lewat. Bounded queue mengubah kontrak tersebut. Setelah kapasitas habis, producer harus menunggu, menerima penolakan, membuang work tertentu, atau mengarahkannya ke tempat lain. Overload tidak lagi tersembunyi di dalam buffer yang terus membesar.

Rekayasa Perangkat Lunak Backpressure

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