Langsung ke konten

Arsip

Rekayasa Perangkat Lunak

127 artikel
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 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 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 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 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 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 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 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 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 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 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 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 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 20 Sep 2026 6 min read

Tombstone Menjaga Delete Antar-Replica hingga Garbage Collection Aman

Tombstone Menjaga Delete Antar-Replica hingga Garbage Collection Aman Menghapus value dari satu salinan replicated data belum berarti menghapusnya dari seluruh sistem. Replica lain mungkin sedang offline, terlambat, atau terpisah oleh partition saat delete terjadi. Jika replica aktif langsung membuang record, bukti bahwa deletion pernah terjadi ikut hilang. Replica stale dapat kembali kemudian dengan value lama dan membuat value tersebut terlihat lagi. Tombstone mengubah deletion menjadi replicated state. Alih-alih langsung menghapus seluruh jejak record, sistem menyimpan marker bahwa record sudah dihapus pada logical point tertentu. Marker tersebut dapat bergerak melalui replication dan repair path yang sama dengan data biasa.

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 20 Sep 2026 6 min read

Rendezvous Hashing Menjaga Penempatan Key Stabil saat Node Berubah

Rendezvous Hashing Menjaga Penempatan Key Stabil saat Node Berubah Sistem terdistribusi sering memerlukan jawaban deterministik untuk penempatan: jika ada sebuah key dan sekumpulan node aktif, node mana yang memiliki key tersebut? Aturan modulo sederhana seperti hash(key) % N memang ringkas, tetapi perubahan N dapat memindahkan sebagian besar key sekaligus. Rendezvous hashing, yang juga disebut highest-random-weight hashing, memakai aturan berbeda. Untuk setiap key, algoritma menghitung score deterministik bagi setiap node yang eligible lalu memilih node dengan score tertinggi. Penambahan atau penghapusan node hanya mengubah penempatan key yang peringkatnya terdampak oleh perubahan membership tersebut.

Rekayasa Perangkat Lunak 20 Sep 2026 6 min read

Idempotency Key Membuat Retry Write Aman Diulang

Idempotency Key Membuat Retry Write Aman Diulang Client dapat kehilangan response dari write yang sebenarnya sudah berhasil. Koneksi mungkin terputus setelah server mencatat pembayaran, membuat order, atau menjadwalkan job, tetapi sebelum response sampai ke caller. Dari sisi client, kegagalan dan keberhasilan dapat terlihat sama. Retry tanpa kontrol berbahaya untuk operasi dengan efek non-idempotent. Mengirim POST yang sama dua kali dapat membuat dua resource atau mengenakan charge dua kali. Tidak melakukan retry juga menyisakan outcome yang ambigu bagi caller.

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 20 Sep 2026 6 min read

Batas Concurrency Adaptif Mengikuti Kapasitas Service

Batas Concurrency Adaptif Mengikuti Kapasitas Service Sebuah service dapat melambat sebelum benar-benar tidak tersedia. Ketika pekerjaan in-flight bertambah, antrean CPU membesar, connection pool terisi, lock contention meningkat, dan panggilan downstream menumpuk. Batas concurrency tetap dapat melindungi service, tetapi satu angka jarang cocok untuk setiap kondisi operasi. Kapasitas berubah mengikuti campuran request, cache hit rate, latency dependency, bentuk deployment, dan tekanan resource. Kontrol concurrency adaptif memperlakukan batas admission sebagai nilai yang dapat bergerak. Controller mengamati perilaku service terbaru, menaikkan batas selama concurrency tambahan masih produktif, lalu menurunkannya ketika latency menunjukkan antrean yang membesar atau saturation. Sasarannya bukan concurrency maksimum, melainkan pekerjaan paralel yang cukup untuk memakai kapasitas tersedia tanpa membiarkan antrean mendominasi response time.

Rekayasa Perangkat Lunak 19 Sep 2026 5 min read

Write Skew Merusak Invariant Lintas Row pada Snapshot Isolation

Snapshot isolation dapat membiarkan dua transaksi commit meskipun hasil gabungannya melanggar aturan yang sudah diperiksa masing-masing transaksi sebelum melakukan write. Anomali ini muncul saat kedua transaksi membaca kondisi logis yang sama, lalu menulis row yang berbeda. Karena write set keduanya tidak beririsan, deteksi konflik write-write biasa tidak memiliki benturan untuk ditolak. Kondisi ini disebut write skew. Batas masalahnya berada di antara invariant aplikasi dan isolation database: sebuah transaksi dapat melihat snapshot yang konsisten, tetapi tetap ikut menghasilkan state akhir yang akan gagal terhadap predicate yang sebelumnya diperiksa.

Rekayasa Perangkat Lunak 19 Sep 2026 6 min read

Sequence Counter Mendeteksi Write Konkuren Tanpa Lock pada Reader

Sequence counter dapat memungkinkan reader menyalin shared state tanpa mengambil lock milik writer. Reader mengambil nilai counter, menyalin field yang dilindungi, lalu mengambil nilai counter sekali lagi. Nilai genap yang sama pada kedua observasi menandakan tidak ada writer yang overlap dengan proses penyalinan berdasarkan kontrak sinkronisasi. Nilai yang berubah atau ganjil memaksa reader membuang snapshot dan mengulang operasi. Pola ini memindahkan pekerjaan dari kepemilikan lock pada sisi reader, tetapi tidak menghapus sinkronisasi. Writer tetap memerlukan serialisasi, transisi counter memerlukan semantik memory ordering yang terdefinisi, dan data yang dilindungi harus tetap aman diakses selama write yang overlap. Constraint tersebut membuat sequence counter cocok untuk sebagian snapshot yang dominan dibaca, tetapi tidak aman untuk data yang lifetime-nya dapat berakhir saat reader masih mengaksesnya.

Rekayasa Perangkat Lunak 19 Sep 2026 8 min read

SaaS Utility Berbasis Iklan: Pertahankan Pemrosesan Stateless dan Data Tetap Ephemeral

SaaS Utility Berbasis Iklan: Pertahankan Pemrosesan Stateless dan Data Tetap Ephemeral SaaS utility tidak membutuhkan operasi konten besar untuk mendapatkan kunjungan berulang. Pengguna bisa datang untuk resize gambar, membersihkan CSV, mengonversi data terstruktur, membuat QR code, memvalidasi dokumen, atau menjalankan transformasi sempit lainnya. Tantangan teknisnya berbeda dari situs konten biasa: setiap kunjungan benar-benar menjalankan pekerjaan. Biaya dapat naik cepat bila setiap request selalu meng-upload file, memakai memori server, menulis object sementara, menyentuh database, lalu menyimpan artifact setelah pengguna pergi. Pada free tier yang dimonetisasi iklan, tekanan ini lebih terasa karena pendapatan per kunjungan biasanya kecil dibanding biaya compute atau storage yang berat.

Rekayasa Perangkat Lunak 19 Sep 2026 6 min read

Request Coalescing Menyatukan Cache Miss Konkuren Menjadi Satu Fill

Cache dapat mengurangi trafik backend pada kondisi stabil, tetapi justru memperbesar kerja saat sebuah entry populer kedaluwarsa. Jika seratus request melihat key yang sama dalam keadaan kosong sebelum nilai pengganti tersimpan, jalur lookup biasa dapat mengirim seratus read yang setara ke origin. Cache tetap bekerja sesuai aturan lookup-nya; amplifikasi muncul dari concurrency selama interval kosong tersebut. Request coalescing mengubah interval itu. Caller pertama untuk sebuah key memulai fill, sedangkan caller berikutnya dengan key yang sama bergabung ke operasi yang sedang berjalan alih-alih memulai kerja setara. Setelah operasi selesai, hasilnya dibagikan kepada caller yang menunggu dan, bila sesuai, disimpan ke cache.

Rekayasa Perangkat Lunak 19 Sep 2026 5 min read

Precondition ETag Mencegah Lost Write pada API Update HTTP

Dua client dapat membaca resource yang sama, mengedit field berbeda, lalu mengirim update dengan selang beberapa detik. Jika server menerima kedua write tanpa memeriksa representasi yang menjadi dasar edit masing-masing client, request yang datang belakangan dapat diam-diam menggantikan state dari write sebelumnya. Transport berhasil, tetapi aplikasi kehilangan perubahan konkuren. HTTP menyediakan mekanisme conditional request untuk batas ini. Server dapat menyertakan entity tag pada representasi, lalu client mengirim kembali tag tersebut melalui If-Match saat mengajukan request yang mengubah state. Update hanya berjalan selama representasi yang dipilih masih memenuhi precondition yang diberikan.