Sistem Terdistribusi

Kecerdasan Buatan / 24 Sep 2026 / 5 min read

Expert Parallelism Mengubah Routing MoE Menjadi Komunikasi All-to-All

Layer Mixture-of-Experts yang aktif secara sparse dapat menyimpan banyak parameter expert sambil mengirim setiap token hanya ke sebagian kecil expert. Ketika expert tersebut dipartisi ke beberapa perangkat, aktivasi sparse tidak berarti eksekusinya tetap lokal. Token yang memilih expert remote harus berpindah ke perangkat pemilik expert, lalu output expert harus kembali ke perangkat yang melanjutkan komputasi model. Perpindahan ini merupakan biaya sistem utama expert parallelism. Router membuat pilihan logis, sedangkan runtime terdistribusi harus mengubah pilihan itu menjadi komunikasi, batch expert lokal, komputasi expert, dan pertukaran balik.

Kecerdasan Buatan Mixture of Experts

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

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