Software Engineering

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

Rekayasa Perangkat Lunak / 19 Sep 2026 / 7 min read

Transactional Outbox Mengikat Perubahan State dengan Intensi Pesan

Service yang memperbarui database dan memublikasikan event ke message broker melewati dua batas commit yang independen. Jika commit database berhasil lalu publish ke broker gagal, state yang durable sudah ada tanpa pesan pasangannya. Membalik urutannya hanya membalik bentuk kegagalan: consumer dapat melihat pesan untuk perubahan state yang pada akhirnya tidak pernah commit. Transactional outbox mempersempit celah ini dengan menempatkan write aplikasi dan record pesan yang durable dalam transaksi database lokal yang sama. Proses publikasi dipindahkan ke relay terpisah. Pola ini tidak membuat database dan broker menjadi satu sistem atomik; batasnya diubah sehingga intensi pesan menjadi bagian dari commit database.

Software Engineering Sistem Terdistribusi

Rekayasa Perangkat Lunak / 19 Sep 2026 / 5 min read

seccomp User Notification Memindahkan Keputusan Syscall Terpilih ke Broker

Filter seccomp dapat melakukan lebih dari sekadar langsung mengizinkan atau menolak system call. Dengan user notification, call yang cocok dapat ditahan sementara proses lain menerima request terstruktur melalui listener file descriptor dan menentukan hasil yang diterima thread yang diblokir. Mekanisme ini mengubah keputusan syscall terpilih menjadi interface berbasis broker tanpa memindahkan seluruh implementasi syscall ke user space. Batasnya presisi, tetapi lebih sempit daripada lapisan interposition umum. Kernel tetap memiliki syscall dispatch, task state, descriptor table, dan validasi yang dilakukan kode kernel. Broker menerima metadata dan dapat mengembalikan nilai, error, atau pada kasus yang didukung meminta eksekusi syscall asli dilanjutkan. Desain yang benar memperhitungkan memory target yang mutable, lifetime notification, serta fakta bahwa keputusan policy tidak otomatis menjadi transaksi atas state proses.

Software Engineering Linux

Rekayasa Perangkat Lunak / 19 Sep 2026 / 6 min read

Request Terhubung io_uring Mengodekan Dependensi dalam Urutan Submission

Submission queue io_uring dapat memuat banyak operasi sekaligus, tetapi setiap operasi tidak harus independen. Menetapkan IOSQE_IO_LINK pada sebuah submission queue entry mengikatnya ke entry berikutnya, membentuk rantai dengan urutan eksekusi dan propagasi kegagalan sebagai bagian dari struktur request yang terlihat oleh kernel. Kontrak ini berbeda dari dua SQE independen yang koordinasinya baru dilakukan setelah completion. Rantai terhubung menyatakan dependensi sebelum kernel mulai memproses operasi. Perbedaan tersebut penting saat request berikutnya hanya valid setelah request sebelumnya selesai, atau saat kegagalan satu tahap harus mencegah tahap yang tersisa dijalankan.

Software Engineering Linux

Rekayasa Perangkat Lunak / 19 Sep 2026 / 6 min read

Propagasi Deadline Membatasi Umur Request Lintas Service

Sebuah request dapat kehilangan kegunaannya sebelum semua proses yang menanganinya berhenti bekerja. HTTP client mungkin berhenti menunggu setelah dua detik, sementara service upstream masih menjalankan database query, RPC, dan rangkaian retry selama beberapa detik berikutnya. Operasi tersebut tetap memakai connection, CPU time, kapasitas queue, dan konkurensi downstream meski hasilnya sudah tidak memiliki penerima. Deadline membuat batas kegunaan itu eksplisit. Propagasi deadline melalui call bertingkat memberi komponen yang terlibat satu batas atas bersama yang berasal dari request awal. Ini berbeda dari pemberian timeout independen pada setiap hop: timeout lokal membatasi operasi individual, sedangkan deadline yang dipropagasikan membatasi umur seluruh graph operasi.

Software Engineering Sistem Terdistribusi

Rekayasa Perangkat Lunak / 19 Sep 2026 / 5 min read

process_vm_readv dan process_vm_writev Mentransfer Memori Melintasi Batas Proses

process_vm_readv() dan process_vm_writev() memungkinkan satu proses Linux menyalin byte secara langsung antara address space miliknya dan address space proses lain. Kedua call bekerja pada vektor rentang memori lokal dan remote, tetapi keberhasilan pencarian proses tidak membuat remote memory menjadi stabil. Perubahan mapping, aksesibilitas page, permission, dan mutasi concurrent tetap menjadi bagian kontrak yang terpisah. Interface ini merupakan system call khusus Linux. Keduanya tidak menetapkan lifetime object C, sinkronisasi, atau model interprocess memory yang portabel.

Software Engineering Linux

Linux / 19 Sep 2026 / 5 min read

process_madvise Menerapkan Memory Advice Lintas Batas Proses

Sebuah proses dapat memakai memory untuk pekerjaan yang koordinasinya berada di komponen lain. Linux process_madvise() memungkinkan koordinator eksternal menerapkan virtual-memory advice terpilih ke rentang dalam proses target tanpa menyuntikkan kode ke proses tersebut. Target diidentifikasi melalui pidfd, sedangkan rentang alamat diberikan sebagai array struct iovec. Susunan ini memisahkan keputusan memory policy dari kode yang memiliki mapping. Runtime manager, service supervisor, atau memory controller dapat meminta perlakuan berorientasi reclaim atau prefetch untuk proses lain, dengan tetap tunduk pada dukungan kernel dan pemeriksaan permission. System call ini tidak memindahkan ownership mapping, tidak membekukan target, dan tidak membuat address space target menjadi statis.

Software Engineering Linux

Rekayasa Perangkat Lunak / 19 Sep 2026 / 6 min read

Notifikasi Prioritas Android Bukan Saluran VIP

Notifikasi Prioritas Android Bukan Saluran VIP Aplikasi Android bergaya pager dapat menyediakan tombol atau menu bernama saluran VIP, tetapi Android tidak mengubah label tersebut menjadi frekuensi radio privat, bearer seluler khusus, atau jalur delivery yang dijamin. Yang dapat dibangun aplikasi adalah kebijakan prioritas. Server dapat mengklasifikasikan event sebagai mendesak, meminta high-priority delivery dari Firebase Cloud Messaging (FCM), lalu menampilkan notifikasi melalui Android notification channel dengan importance tinggi. Kontrol tersebut bekerja pada layer yang berbeda, dan tidak satu pun sendirian memberikan jaminan delivery seperti yang sering dibayangkan dari sebuah pager.

Software Engineering Android

Rekayasa Perangkat Lunak / 19 Sep 2026 / 8 min read

MQTT dan QUIC Menyelesaikan Bagian Berbeda dari Transport Chat

MQTT dan QUIC Menyelesaikan Bagian Berbeda dari Transport Chat MQTT dan QUIC sering ditempatkan dalam tabel perbandingan yang sama ketika membahas chat real-time. Perbandingan itu praktis, tetapi mencampur dua layer protokol yang berbeda menjadi satu pilihan. MQTT adalah protokol messaging pada application layer. Ia mendefinisikan konsep seperti client, broker, topic, subscription, retained message, session state, dan quality of service untuk delivery. QUIC adalah protokol transport aman di atas UDP. Ia menyediakan connection, stream, flow control, loss recovery, encryption, dan mekanisme connection migration.

Software Engineering MQTT

Rekayasa Perangkat Lunak / 19 Sep 2026 / 6 min read

Linux membarrier Memindahkan Biaya Memory Ordering ke Thread Koordinator

Sebuah runtime concurrent dapat menjalankan ribuan operasi fast path untuk setiap transisi state langka yang membutuhkan koordinasi global. Menempatkan full memory barrier pada setiap fast path membuat seluruh operasi membayar biaya transisi yang jarang terjadi itu. Linux membarrier() mendukung susunan sebaliknya: thread koordinator masuk ke kernel dan memaksakan titik ordering yang terdefinisi pada sekumpulan thread target, sehingga biaya yang lebih besar berpindah ke sisi protokol yang jarang dijalankan. Mekanisme ini bukan pengganti umum untuk atomic, mutex, atau memory model bahasa pemrograman. Ini adalah antarmuka kernel Linux dengan jaminan yang berlaku pada akses memory dan thread target berdasarkan command tertentu. Penggunaan yang benar memerlukan protokol yang sudah menentukan akses mana yang terjadi sebelum dan sesudah titik koordinasi.

Software Engineering Linux

Rekayasa Perangkat Lunak / 19 Sep 2026 / 5 min read

Kolom Versi Mengubah Update Database Menjadi Transisi State Bersyarat

Client database dapat membaca sebuah row, memakai waktu untuk menghitung perubahan, lalu menjalankan UPDATE setelah transaksi lain lebih dulu mengubah row yang sama. Jika statement terakhir hanya mengidentifikasi row lewat primary key, write yang datang kemudian dapat mengganti state yang dihitung dari kondisi lama tanpa konflik yang terlihat. Kolom versi mengubah batas tersebut. Client membaca state aplikasi beserta nilai revisinya, lalu menyertakan revisi itu dalam predicate update. Database menerima write hanya selama revisi yang tersimpan masih sama dengan state yang sebelumnya diamati client.

Software Engineering Database

Rekayasa Perangkat Lunak / 19 Sep 2026 / 7 min read

Idempotency Key Mengikat Retry ke Satu Mutasi Logis

Client dapat kehilangan HTTP response setelah server melakukan commit terhadap mutasi yang diminta. Dari sisi client, status operasi belum pasti: koneksi gagal, tetapi kegagalan itu tidak menunjukkan apakah durable state sudah berubah. Retry terhadap POST yang sama kemudian dapat membuat order, percobaan pembayaran, reservasi, atau mutasi lain untuk kedua kalinya. Idempotency key memberi retry sebuah identitas stabil yang terpisah dari satu percobaan transport tertentu. Server dapat mengaitkan request berulang yang membawa identitas tersebut dengan satu operasi logis. Mekanisme ini mempersempit ambiguitas pada batas API, tetapi key saja bukan jaminan. Scope, persistensi, perbandingan request, kontrol konkurensi, dan kebijakan replay menentukan arti sebenarnya dari pengiriman berulang.

Software Engineering HTTP

Rekayasa Perangkat Lunak / 19 Sep 2026 / 6 min read

Idempotency Key Membatasi Keamanan Retry pada Identitas Request

Client dapat mengirim operasi logis yang sama lebih dari sekali meski hanya menginginkan satu efek. Timeout setelah POST /payments meninggalkan batas yang ambigu: server mungkin sudah melakukan commit pembayaran sementara client tidak menerima response. Retry memulihkan pengiriman, tetapi retry biasa dapat membuat pembayaran kedua. Idempotency key mengubah interface dengan memberi identitas request yang stabil pada percobaan berulang. Key tersebut bukan pengganti transactionality dan tidak membuat setiap operasi secara intrinsik idempotent. Key membentuk protokol antara client dan server: percobaan dengan key yang sama diperlakukan sebagai kandidat untuk operasi logis yang sama. Server tetap memerlukan aturan mengenai ekuivalensi request, kedatangan konkuren, masa persistensi, pemulihan kegagalan, dan replay response.

Software Engineering API

Rekayasa Perangkat Lunak / 19 Sep 2026 / 6 min read

Generation Counter Menjaga Handle yang Dipakai Ulang Tetap Terikat ke Resource yang Tepat

Handle yang ringkas sering direpresentasikan sebagai integer karena murah untuk disimpan, disalin, dibandingkan, dan diteruskan melewati batas API. Pada resource manager berbasis tabel, integer tersebut dapat berupa index ke array slot. Representasi ini bermasalah saat sebuah slot dilepas lalu dipakai kembali. Handle lama dapat menunjuk resource baru yang kebetulan menempati index yang sama. Kegagalannya bukan akses di luar batas array. Index tersebut bisa sepenuhnya valid. Masalahnya ada pada identitas: handle menyebut lokasi penyimpanan, sementara caller memperlakukannya sebagai identitas resource yang sebelumnya menempati lokasi itu.

Software Engineering Manajemen Resource

Rekayasa Perangkat Lunak / 19 Sep 2026 / 7 min read

FCM Adalah Jalur Wake-Up, Bukan Transport Real-Time

FCM Adalah Jalur Wake-Up, Bukan Transport Real-Time Aplikasi mobile dapat mempertahankan WebSocket ketika aktif dan tetap membutuhkan Firebase Cloud Messaging saat sistem operasi menangguhkannya. Kedua mekanisme itu menangani kondisi kegagalan yang berbeda. WebSocket, MQTT, dan SignalR mengasumsikan client dapat berpartisipasi dalam sesi komunikasi yang hidup. FCM justru berguna ketika asumsi itu tidak lagi berlaku: aplikasi mungkin berada di background, prosesnya mungkin tidak berjalan, atau koneksi persistennya sudah hilang. Menganggap FCM sebagai transport real-time lain menyamarkan boundary tersebut. Desain yang lebih kuat memakai live channel selama tersedia dan memperlakukan push delivery sebagai sinyal agar aplikasi kembali aktif lalu merekonsiliasi state.

Software Engineering FCM

Rekayasa Perangkat Lunak / 19 Sep 2026 / 5 min read

EPOLLET Menjadikan Readiness sebagai Kontrak Transisi State

Descriptor yang didaftarkan dengan EPOLLET dapat tetap readable setelah sebuah event dikirim tanpa muncul lagi pada epoll_wait() berikutnya. Kernel melaporkan transisi readiness; kernel tidak menjanjikan pengulangan notifikasi yang sama hanya karena masih ada data yang belum dibaca. Perbedaan ini menjadikan edge-triggered epoll sebagai kontrak transisi state antara kernel dan event loop. Konsekuensinya bersifat struktural. Handler tidak dapat memperlakukan satu event sebagai izin untuk satu read() lalu langsung kembali ke wait loop. Pada edge-triggered monitoring, handler harus memperhitungkan seluruh state I/O yang segera tersedia sebelum bergantung pada transisi berikutnya.

Software Engineering Linux

Rekayasa Perangkat Lunak / 19 Sep 2026 / 7 min read

Compose Multiplatform vs Flutter: Rendering, Performa, dan Ukuran Bundle

Compose Multiplatform vs Flutter: Rendering, Performa, dan Ukuran Bundle Compose Multiplatform dan Flutter dapat menghasilkan UI mobile yang sama-sama mulus, tetapi jalur yang mereka tempuh sampai pixel muncul di layar tidak sama. Perbedaan ini lebih penting daripada sekadar membandingkan “Kotlin versus Dart”. Compose Multiplatform memperluas model pemrograman Compose ke beberapa platform. Flutter membawa UI stack yang lebih mandiri bersama engine dan Dart runtime miliknya. Keduanya menambahkan komponen di luar kode aplikasi, tetapi biayanya muncul di tempat berbeda: rendering, startup, memory, ukuran binary, dan integrasi platform.

Software Engineering Compose Multiplatform

Rekayasa Perangkat Lunak / 19 Sep 2026 / 6 min read

Circuit Breaker Membatasi Trafik Kegagalan Lintas Panggilan Service

Circuit breaker mengubah keputusan admission untuk panggilan keluar sebelum dependency menerimanya. Pada state closed, panggilan diteruskan dan hasilnya menjadi input bagi kebijakan kegagalan. Setelah kebijakan tersebut terpicu, breaker masuk ke state open dan menolak panggilan berikutnya secara lokal. Setelah interval pemulihan yang dikonfigurasi berakhir, sejumlah terbatas panggilan probe dapat menguji apakah dependency sudah dapat dipakai kembali. Mekanisme ini berbeda dari retry. Retry mengirim percobaan lain setelah sebuah percobaan gagal. Breaker dapat mencegah sebuah percobaan dikirim sama sekali. Menggabungkan keduanya tanpa urutan yang presisi dapat memperbesar trafik saat terjadi gangguan atau mempertahankan breaker dalam state open berdasarkan sinyal yang tidak merepresentasikan kondisi dependency.

Software Engineering Sistem Terdistribusi

Rekayasa Perangkat Lunak / 19 Sep 2026 / 6 min read

Circuit Breaker Membatasi Amplifikasi Kegagalan Antar-Service

Sebuah service call dapat gagal dengan cepat tetapi tetap menimbulkan masalah yang lebih besar pada sistem. Ketika setiap request upstream terus memanggil dependency downstream yang sedang gagal, setiap percobaan menghabiskan kapasitas koneksi, waktu worker, retry budget, dan ruang queue. Dependency menerima traffic yang belum mampu dilayaninya, sementara caller menghabiskan resource untuk menunggu hasil yang sangat berkorelasi dengan kegagalan sebelumnya. Circuit breaker menempatkan batas keputusan yang memiliki state di depan call tersebut. Alih-alih memperlakukan setiap request sebagai kesempatan terpisah untuk mencoba dependency, breaker mencatat state kegagalan terbaru dan dapat menolak call secara lokal selama interval terbatas. Pemulihan kemudian diuji melalui probe terkontrol, bukan dengan langsung mengembalikan seluruh traffic.

Software Engineering Sistem Terdistribusi

Rekayasa Perangkat Lunak / 19 Sep 2026 / 7 min read

Cara Runtime Bahasa Memakai Core CPU: Thread, Goroutine, Worker, dan Proses

CPU dengan banyak core tidak membuat kode aplikasi menjadi paralel dengan sendirinya. Sistem operasi memang dapat menjadwalkan beberapa thread pada saat yang sama, tetapi bahasa dan runtime menentukan bagaimana pekerjaan aplikasi mencapai thread tersebut. Perbedaan ini menjelaskan mengapa Go, Rust, C++, Java, JavaScript, dan PHP sama-sama dapat memakai mesin multicore meskipun model pemrogramannya sangat berbeda. Pertanyaan yang lebih berguna bukan sekadar apakah sebuah bahasa “multithreaded”. Yang perlu dilihat adalah bagaimana satu unit pekerjaan aplikasi berubah menjadi sesuatu yang dapat dijadwalkan oleh sistem operasi.

Software Engineering Concurrency