Reliability

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

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

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

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

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

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