Rekayasa Perangkat Lunak

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

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

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 Sistem Terdistribusi

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

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

Rekayasa Perangkat Lunak / 20 Sep 2026 / 6 min read

Consistent Hashing Membatasi Perpindahan Key Saat Node Berubah

Partisi dengan hash(key) % N sederhana selama jumlah node tetap. Aritmetika tersebut menjadi disruptif ketika N berubah. Peralihan dari empat node ke lima node mengganti pembagi, sehingga banyak key memilih remainder berbeda meskipun hanya satu node yang bergabung. Consistent hashing mengubah pemetaan tersebut. Key dan node ditempatkan dalam hash space melingkar yang sama. Sebuah key menjadi milik node pertama yang ditemui dalam arah yang dipilih pada ring. Penambahan atau penghapusan node hanya mengubah kepemilikan range yang berdekatan dengan perubahan membership itu.

Software Engineering Sistem Terdistribusi

Rekayasa Perangkat Lunak / 20 Sep 2026 / 4 min read

Circuit Breaker Membatasi Panggilan Berulang ke Dependency yang Gagal

Circuit Breaker Membatasi Panggilan Berulang ke Dependency yang Gagal Dependency remote dapat gagal dengan cara yang lambat sekaligus mahal. Request menunggu timeout, worker tetap terpakai, retry menambah traffic, dan service lokal dapat kehilangan kapasitas walaupun kodenya sendiri tetap sehat. Circuit breaker menempatkan keputusan berbasis state di depan jalur panggilan tersebut. Selama dependency bekerja dalam batas yang dapat diterima, panggilan diteruskan. Setelah kondisi kegagalan yang ditetapkan tercapai, breaker masuk ke state open dan menolak panggilan baru secara lokal selama periode terbatas. Setelah itu, sejumlah kecil probe diizinkan sebelum traffic normal dapat kembali.

Software Engineering Resiliensi

Rekayasa Perangkat Lunak / 20 Sep 2026 / 6 min read

Bulkhead Mengisolasi Resource Pool Sebelum Kegagalan Menyebar

Sebuah service dapat tetap sehat pada level proses tetapi menjadi tidak berguna karena satu workload menghabiskan seluruh resource eksekusi yang langka. Dependency yang lambat dapat menahan semua outbound connection. Tenant yang sangat aktif dapat memenuhi setiap worker slot. Background job dapat mengambil semaphore permit yang sama dengan request interaktif. Isolasi bulkhead membatasi keterkaitan tersebut. Alih-alih membiarkan pekerjaan yang tidak berkaitan berebut satu pool tanpa pembagian, sistem mempartisi resource tertentu dan memberi setiap kelas pekerjaan bagian yang terbatas. Saturasi kemudian memiliki blast radius yang lebih kecil.

Software Engineering Bulkhead

Rekayasa Perangkat Lunak / 20 Sep 2026 / 5 min read

Bulkhead Mengisolasi Concurrency Antar-Dependency

Bulkhead Mengisolasi Concurrency Antar-Dependency Sebuah service dapat memiliki CPU yang masih longgar tetapi tetap tidak tersedia karena satu dependency berhenti menyelesaikan pekerjaan. Request yang menunggu database, remote API, atau storage service yang lambat tetap menahan slot eksekusi, connection, memory, dan posisi queue. Jika operasi yang tidak berkaitan memakai finite pool yang sama, satu jalur yang jenuh dapat menghabiskan kapasitas yang dibutuhkan jalur sehat. Isolasi bulkhead membagi concurrency bersama itu menjadi budget yang eksplisit. Panggilan ke satu dependency atau kelas workload memakai bounded pool yang tidak dapat dihabiskan kelas lain. Pola ini tidak memperbaiki dependency yang gagal. Fungsinya membatasi kapasitas lokal yang dapat ditempati kegagalan tersebut.

Software Engineering Concurrency

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 Sistem Terdistribusi

Rekayasa Perangkat Lunak / 20 Sep 2026 / 5 min read

Backpressure Mengikat Kecepatan Producer pada Kapasitas Consumer

Producer yang cepat dan consumer yang lebih lambat dapat berjalan aman hanya selama selisih laju keduanya tetap terbatas. Jika pekerjaan masuk lebih cepat daripada kemampuan penyelesaiannya dalam waktu yang cukup lama, buffering tidak menghapus overload. Buffer hanya menyimpan selisih tersebut. Backpressure menjadikan ketimpangan kapasitas itu bagian dari protokol antarkomponen. Alih-alih menerima pekerjaan tanpa batas, stage yang jenuh membuat kode upstream melambat, menunggu kapasitas, mengurangi demand, atau menolak pekerjaan berdasarkan kebijakan yang eksplisit.

Software Engineering Backpressure