Jelajahi bagaimana Joe Armstrong membentuk konkurensi Erlang, supervisi, dan pola “let it crash”—ide-ide yang masih dipakai untuk membangun layanan real-time andal.
Joe Armstrong bukan hanya salah satu pencipta Erlang—ia juga penjelas paling jelas dan persuasifnya. Lewat ceramah, makalah, dan pendekatan pragmatis, ia memopulerkan ide sederhana: jika Anda ingin perangkat lunak yang tetap berjalan, rancang untuk kegagalan daripada pura‑pura bisa menghindarinya.
Tulisan ini adalah tur berpemandu tentang pola pikir Erlang dan mengapa itu masih relevan saat Anda membangun platform real-time yang andal—seperti sistem chat, routing panggilan, notifikasi langsung, koordinasi multiplayer, dan infrastruktur yang harus merespons cepat dan konsisten meski sebagian komponennya bermasalah.
Real-time tidak selalu berarti “mikrodetik” atau “batas waktu keras.” Dalam banyak produk itu berarti:
Erlang dibangun untuk sistem telekomunikasi di mana ekspektasi ini tak bisa dinegosiasikan—dan tekanan itu membentuk gagasan‑gagasan paling berpengaruhnya.
Daripada masuk ke sintaks, kita akan fokus pada konsep yang membuat Erlang terkenal dan terus muncul ulang dalam desain sistem modern:
Sepanjang jalan, kita akan mengaitkan ide‑ide ini dengan model aktor dan message passing, menjelaskan pohon supervisi dan OTP secara mudah dipahami, dan menunjukkan mengapa BEAM VM membuat pendekatan ini praktis.
Bahkan jika Anda tidak menggunakan Erlang (dan takkan pernah), intinya tetap: framing Armstrong memberi Anda checklist kuat untuk membangun sistem yang tetap responsif dan tersedia saat kenyataan menjadi berantakan.
Switch telekom dan platform routing panggilan tidak bisa “mati untuk pemeliharaan” sebagaimana banyak situs web. Mereka diharapkan terus menangani panggilan, event penagihan, dan trafik signaling sepanjang waktu—sering dengan persyaratan ketersediaan dan waktu respons yang ketat.
Erlang lahir di dalam Ericsson akhir 1980‑an sebagai upaya memenuhi realitas itu dengan perangkat lunak, bukan hanya hardware khusus. Joe Armstrong dan rekan‑rekannya bukan mengejar keanggunan demi keanggunan; mereka mencoba membangun sistem yang dapat dipercaya operator di bawah beban konstan, kegagalan parsial, dan kondisi dunia nyata yang berantakan.
Perubahan pola pikir kunci adalah bahwa reliabilitas bukanlah sama dengan “tidak pernah gagal.” Dalam sistem besar yang berjalan lama, sesuatu akan gagal: sebuah proses akan menerima input tak terduga, sebuah node akan reboot, link jaringan akan flapping, atau dependensi akan macet.
Jadi tujuannya menjadi:
Inilah mindset yang kemudian membuat ide seperti pohon supervisi dan “let it crash” terasa masuk akal: Anda merancang kegagalan sebagai kejadian normal, bukan bencana istimewa.
Mudah saja menceritakan kisah sebagai terobosan satu visioner. Sudut pandang yang lebih berguna lebih sederhana: keterbatasan telekom memaksa trade‑off berbeda. Erlang memprioritaskan konkurensi, isolasi, dan pemulihan karena itu alat praktis yang diperlukan untuk menjaga layanan tetap berjalan sementara dunia terus berubah di sekitarnya.
Pendekatan berfokus‑masalah ini juga alasan kenapa pelajaran Erlang masih terjemah dengan baik hari ini—di mana uptime dan pemulihan cepat lebih penting daripada pencegahan sempurna.
Ide inti Erlang adalah bahwa “melakukan banyak hal sekaligus” bukan fitur khusus yang ditambahkan kemudian—itu cara normal Anda menyusun sistem.
Di Erlang, pekerjaan dibagi menjadi banyak “proses” kecil. Pikirkan mereka sebagai pekerja kecil, masing‑masing bertanggung jawab pada satu tugas: menangani panggilan telepon, melacak sesi chat, memantau perangkat, mencoba ulang pembayaran, atau mengawasi antrean.
Mereka ringan, artinya Anda bisa memiliki jumlah besar tanpa perlu hardware besar. Alih‑alih satu pekerja berat mencoba menangani semuanya, Anda punya kerumunan pekerja fokus yang bisa mulai cepat, berhenti cepat, dan diganti cepat.
Banyak sistem dirancang seperti satu program besar dengan banyak bagian yang saling terkait erat. Saat sistem seperti itu terkena bug serius, masalah memori, atau operasi blocking, kegagalan bisa merambat—seperti memutus satu pemutus dan memadamkan seluruh gedung.
Erlang mendorong kebalikan: isolasi tanggung jawab. Jika satu pekerja kecil bermasalah, Anda bisa menghentikan dan mengganti pekerja itu tanpa menjatuhkan pekerjaan lain yang tak terkait.
Bagaimana para pekerja ini berkoordinasi? Mereka tidak mengubah state internal satu sama lain. Mereka mengirim pesan—lebih mirip mengirim catatan daripada berbagi papan tulis yang berantakan.
Satu pekerja bisa berkata, “Ada permintaan baru,” “Pengguna ini terputus,” atau “Coba lagi dalam 5 detik.” Penerima membaca catatan itu dan memutuskan apa yang harus dilakukan.
Manfaat utamanya adalah penahanan: karena pekerja terisolasi dan berkomunikasi lewat pesan, kegagalan kecil cenderung tak menyebar ke seluruh sistem.
Cara sederhana memahami "model aktor" Erlang adalah membayangkan sistem yang tersusun dari banyak pekerja kecil, independen.
Sebuah aktor adalah unit tertutup dengan state privat dan sebuah mailbox. Ia melakukan tiga hal dasar:
Cukup itu. Tidak ada variabel bersama tersembunyi, tidak ada “mengutak‑atik memori pekerja lain.” Jika satu aktor butuh sesuatu dari lainnya, ia meminta dengan mengirim pesan.
Saat multiple thread berbagi data yang sama, Anda bisa mendapat race condition: dua kejadian mengubah nilai yang sama hampir bersamaan, dan hasil bergantung pada timing. Itulah bug yang bersifat intermiten dan sulit direproduksi.
Dengan message passing, setiap aktor memiliki data sendiri. Aktor lain tidak bisa memutasi langsung. Ini tidak menghilangkan semua bug, tetapi secara dramatis mengurangi masalah yang disebabkan oleh akses simultan ke data yang sama.
Pesan tidak datang “gratis.” Jika sebuah aktor menerima pesan lebih cepat daripada yang bisa diproses, mail‑box‑nya (antrian) akan tumbuh. Itu back‑pressure: sistem memberi tahu, secara tidak langsung, “bagian ini kewalahan.”
Dalam praktiknya, Anda memantau ukuran mailbox dan menetapkan batas: menurunkan beban, membatch, sampling, atau menyebarkan pekerjaan ke lebih banyak aktor alih‑alih membiarkan antrean membesar selamanya.
Bayangkan sebuah aplikasi chat. Setiap pengguna bisa punya aktor yang bertugas mengirim notifikasi. Ketika pengguna offline, pesan terus datang—jadi mailbox tumbuh. Sistem yang baik mungkin membatasi antrean, menjatuhkan notifikasi non‑kritis, atau beralih ke mode digest, daripada membiarkan satu pengguna lambat menurunkan layanan seluruh sistem.
“Let it crash” bukan slogan untuk engineering ceroboh. Ini strategi reliabilitas: ketika sebuah komponen memasuki keadaan buruk atau tak terduga, ia harus berhenti cepat dan jelas daripada berjalan pincang.
Daripada menulis kode yang mencoba menangani semua edge case di dalam satu proses, Erlang mendorong menjaga setiap pekerja kecil dan fokus. Jika pekerja itu terkena sesuatu yang benar‑benar tidak bisa ditangani (state korup, asumsi dilanggar, input tak terduga), ia keluar. Bagian lain sistem bertanggung jawab menghidupkannya kembali.
Ini menggeser pertanyaan utama dari “Bagaimana kita mencegah kegagalan?” ke “Bagaimana kita pulihkan dengan rapi saat kegagalan terjadi?”
Pemrograman defensif di mana‑mana bisa mengubah alur sederhana menjadi labirin kondisional, retry, dan state parsial. “Let it crash” menukar beberapa kompleksitas in‑process itu untuk:
Gagasan besarnya: pemulihan harus dapat diprediksi dan dapat diulang, bukan improvisasi di setiap fungsi.
Cocok ketika kegagalan bisa dipulihkan dan terisolasi: masalah jaringan sementara, permintaan buruk, pekerja macet, timeout pihak ketiga.
Tidak cocok bila crash dapat menyebabkan kerusakan tak terbalikkan, seperti:
Crashing hanya membantu jika kembali dengan cepat dan aman. Itu berarti me‑restart pekerja ke state yang diketahui baik—sering kali dengan memuat ulang konfigurasi, membangun kembali cache in‑memory dari penyimpanan tahan lama, dan meneruskan kerja tanpa berpura‑pura state rusak tak pernah ada.
Ide “let it crash” hanya bekerja karena crash tidak dibiarkan begitu saja. Pola kunci adalah pohon supervisi: hirarki di mana supervisor bertindak seperti manajer dan worker melakukan pekerjaan nyata (menangani panggilan, mengawasi sesi, mengonsumsi antrean, dll.). Ketika worker bermasalah, manajer melihat dan me‑restart‑nya.
Supervisor tidak mencoba “memperbaiki” worker yang rusak di tempat. Sebaliknya, ia menerapkan aturan sederhana dan konsisten: jika worker mati, jalankan yang baru. Itu membuat jalur pemulihan dapat diprediksi dan mengurangi kebutuhan error handling ad‑hoc yang tersebar di kode.
Sama pentingnya, supervisor bisa memutuskan kapan tidak me‑restart—jika sesuatu terus‑menerus crash, itu indikasi masalah lebih dalam, dan restart berulang bisa memperburuk keadaan.
Supervisi bukan satu ukuran cocok untuk semua. Strategi umum meliputi:
Desain supervisi yang baik dimulai dari peta ketergantungan: komponen mana bergantung ke mana, dan apa arti “fresh start” untuk mereka.
Jika handler sesi bergantung pada proses cache, me‑restart hanya handler mungkin meninggalkannya terhubung ke state buruk. Mengelompokkan mereka di bawah supervisor yang tepat (atau me‑restart bersama) mengubah mode kegagalan yang berantakan menjadi perilaku pemulihan yang konsisten dan dapat diulang.
Jika Erlang adalah bahasa, OTP (Open Telecom Platform) adalah kotak bagian yang mengubah “let it crash” menjadi sesuatu yang bisa dijalankan di produksi selama bertahun‑tahun.
OTP bukan sekadar library—itu kumpulan konvensi dan komponen siap‑pakai (disebut behaviours) yang menyelesaikan bagian membosankan tapi penting dari membangun layanan:
gen_server untuk worker berumur panjang yang menyimpan state dan menangani permintaan satu per satusupervisor untuk otomatis me‑restart worker yang gagal menurut aturan jelasapplication untuk mendefinisikan bagaimana satu layanan dimulai, dihentikan, dan masuk ke rilisMereka bukan “sihir.” Mereka template dengan callback terdefinisi, sehingga kode Anda menyatu ke bentuk yang dikenal alih‑alih menciptakan bentuk baru tiap proyek.
Tim sering membuat worker background ad‑hoc, hook monitoring rumahan, dan logika restart satu kali. Itu berhasil—sampai tidak. OTP mengurangi risiko itu dengan mendorong semua orang ke kosakata dan lifecycle yang sama. Ketika engineer baru bergabung, mereka tak perlu mempelajari framework custom terlebih dahulu; mereka mengandalkan pola yang umum dipahami di ekosistem Erlang.
OTP mendorong Anda berpikir dalam peran proses dan tanggung jawab: apa itu worker, apa itu koordinator, apa yang harus me‑restart apa, dan apa yang tak boleh di‑restart otomatis.
Ia juga mendorong kebersihan operasional: penamaan jelas, urutan startup eksplisit, shutdown yang dapat diprediksi, dan sinyal monitoring bawaan. Hasilnya adalah perangkat lunak yang didesain untuk berjalan terus—layanan yang bisa pulih dari kesalahan, berevolusi seiring waktu, dan tetap melakukan pekerjaan tanpa pengasuhan manusia terus‑menerus.
Ide besar Erlang—proses kecil, message passing, dan “let it crash”—akan jauh lebih sulit digunakan di produksi tanpa BEAM (virtual machine). BEAM adalah runtime yang membuat pola‑pola ini terasa alami, bukan rapuh.
BEAM dirancang untuk menjalankan banyak proses ringan. Alih‑alih mengandalkan beberapa thread OS dan berharap aplikasi berperilaku, BEAM mengatur penjadwalan proses Erlang sendiri.
Manfaat praktisnya adalah responsivitas saat beban: pekerjaan diiris menjadi potongan kecil dan diputar secara adil, sehingga tak ada pekerja sibuk yang mendominasi sistem terlalu lama. Itu cocok sekali dengan layanan yang tersusun dari banyak tugas independen—masing‑masing melakukan sedikit kerja, kemudian memberi kesempatan.
Setiap proses Erlang memiliki heap sendiri dan garbage collection sendiri. Ini detail kunci: membersihkan memori di satu proses tidak memerlukan jeda seluruh program.
Selain itu, proses terisolasi. Jika satu crash, ia tidak merusak memori proses lain, dan VM tetap hidup. Isolasi ini adalah fondasi yang membuat pohon supervisi realistis: kegagalan dikandung, lalu ditangani dengan me‑restart bagian yang gagal alih‑alih merobohkan semuanya.
BEAM juga mendukung distribusi dengan cara yang sederhana: Anda bisa menjalankan banyak node Erlang (instance VM terpisah) dan membiarkan mereka berkomunikasi lewat pesan. Jika Anda memahami “proses saling bicara lewat pesan,” distribusi adalah perpanjangan dari ide yang sama—beberapa proses kebetulan hidup di node lain.
BEAM bukan janji kecepatan mentah. Ia membuat konkurensi, isolasi kegagalan, dan pemulihan menjadi default, sehingga cerita reliabilitasnya praktis bukan teoretis.
Salah satu trik Erlang yang sering dibicarakan adalah hot code swapping: memperbarui bagian sistem yang sedang berjalan dengan downtime minimal (dengan dukungan runtime dan tooling). Janji praktisnya bukan “tak perlu restart lagi,” melainkan “kirim perbaikan tanpa mengubah bug kecil menjadi outage panjang.”
Di Erlang/OTP, runtime dapat memuat dua versi modul secara bersamaan. Proses yang sudah ada bisa menyelesaikan kerja menggunakan versi lama sementara panggilan baru bisa memakai versi baru. Itu memberi ruang untuk menambal bug, meluncurkan fitur, atau menyesuaikan perilaku tanpa mengusir semua orang dari sistem.
Jika dilakukan dengan baik, ini mendukung tujuan reliabilitas langsung: lebih sedikit restart penuh, jendela maintenance lebih pendek, dan pemulihan lebih cepat saat sesuatu kebobolan ke produksi.
Tidak semua perubahan aman disisipkan hidup‑hidup. Contoh perubahan yang butuh kehati‑hatian ekstra (atau restart):
Erlang menyediakan mekanisme untuk transisi terkontrol, tapi Anda tetap harus merancang jalur upgrade.
Hot upgrade bekerja terbaik bila upgrade dan rollback diperlakukan sebagai operasi rutin, bukan darurat langka. Itu berarti merencanakan versioning, kompatibilitas, dan jalur “undo” sejak awal. Praktiknya, tim memadukan teknik live‑upgrade dengan rollout bertahap, health check, dan pemulihan berbasis supervisi.
Bahkan jika Anda tidak memakai Erlang, pelajaran yang bisa dibawa pulang: desain sistem sehingga mengubahnya dengan aman adalah kebutuhan utama, bukan pemikiran belakangan.
Platform real‑time kurang soal timing sempurna dan lebih soal tetap responsif saat segala hal terus‑menerus rusak: jaringan goyah, dependensi melambat, dan lonjakan trafik. Desain Erlang—yang dipopulerkan Joe Armstrong—cocok karena menganggap kegagalan dan memperlakukan konkurensi sebagai normal, bukan luar biasa.
Anda melihat pemikiran bergaya Erlang bersinar di mana ada banyak aktivitas independen terjadi bersamaan:
Kebanyakan produk tidak butuh jaminan keras seperti “setiap aksi selesai dalam 10 ms.” Mereka butuh soft real‑time: latensi rendah yang konsisten untuk permintaan tipikal, pemulihan cepat saat bagian gagal, dan ketersediaan tinggi supaya pengguna jarang merasakan insiden.
Sistem nyata menemui masalah seperti:
Model Erlang mendorong mengisolasi tiap aktivitas (sesi pengguna, perangkat, percobaan pembayaran) sehingga kegagalan tak menyebar. Alih‑alih membangun satu komponen raksasa yang “mencoba menangani semua,” tim dapat berpikir dalam unit kecil: setiap worker melakukan satu tugas, bicara lewat pesan, dan jika rusak, di‑restart bersih.
Perpindahan paradigma—dari “mencegah setiap kegagalan” ke “mengandung dan memulihkan kegagalan dengan cepat”—sering membuat platform real‑time terasa stabil di bawah tekanan.
Reputasi Erlang terkadang terdengar seperti janji: sistem yang tidak pernah turun karena terus me‑restart. Kenyataannya lebih praktis—dan lebih berguna. “Let it crash” adalah alat untuk membangun layanan dapat diandalkan, bukan lisensi mengabaikan masalah berat.
Kesalahan umum adalah menganggap supervisi sebagai cara menyembunyikan bug dalam. Jika proses crash segera setelah mulai, supervisor bisa terus me‑restart sampai Anda berujung pada crash loop—membakar CPU, mengisi log, dan mungkin menyebabkan outage yang lebih besar daripada bug awal.
Sistem baik menambahkan backoff, batas intensitas restart, dan perilaku “berhenti dan eskalasi” yang jelas. Restart harus mengembalikan operasi sehat, bukan menyamarkan invariant yang rusak.
Me‑restart proses sering mudah; memulihkan state yang benar sering tidak. Jika state hanya di memori, Anda harus memutuskan apa arti “benar” setelah crash:
Toleransi kesalahan tidak menggantikan desain data yang matang. Ia memaksa Anda menjadi eksplisit tentang itu.
Crash hanya berguna jika Anda dapat melihatnya lebih awal dan memahaminya. Itu berarti investasi pada logging, metrik, dan tracing—bukan sekadar “ia restart, jadi baik.” Anda ingin melihat kenaikan tingkat restart, antrean yang membesar, dan dependensi yang melambat sebelum pengguna merasakannya.
Bahkan dengan kekuatan BEAM, sistem bisa gagal dalam cara yang biasa:
Model Erlang membantu menahan dan memulihkan kegagalan—tapi ia tidak menghapusnya.
Hadiah terbesar Erlang bukan sintaks—melainkan seperangkat kebiasaan untuk membangun layanan yang tetap jalan ketika bagian pasti gagal. Anda bisa menerapkan kebiasaan itu di hampir semua stack.
Mulailah dengan membuat batas kegagalan eksplisit. Pecah sistem menjadi komponen yang dapat gagal secara independen, dan pastikan tiap komponen punya kontrak jelas (input, output, dan apa yang dianggap “buruk”).
Lalu otomatisasi pemulihan alih‑alih mencoba mencegah tiap kesalahan:
Salah satu cara praktis membuat kebiasaan ini menjadi nyata adalah memasukkannya ke tooling dan lifecycle, bukan sekadar kode. Misalnya, ketika tim menggunakan Koder.ai untuk vibe‑code web, backend, atau mobile via chat, workflow mendorong perencanaan eksplisit (Planning Mode), deployment yang dapat diulang, dan iterasi aman dengan snapshot dan rollback—konsep yang selaras dengan mindset operasional yang dipopulerkan Erlang: anggap perubahan dan kegagalan akan terjadi, dan jadikan pemulihan membosankan.
Anda dapat meniru pola “supervisi” dengan alat yang mungkin sudah digunakan:
Sebelum mengadopsi pola, tentukan apa yang benar‑benar Anda butuhkan:
Jika Anda ingin langkah praktis selanjutnya, lihat panduan lain di /blog, atau jelajahi detail implementasi di /docs (dan rencana di /pricing bila Anda mengevaluasi tooling).
Erlang memopulerkan pola pemikiran reliabilitas yang praktis: anggap bagian-bagian akan gagal dan rancangkan apa yang terjadi selanjutnya.
Daripada mencoba mencegah setiap kegagalan, pendekatan ini menekankan isolasi kegagalan, deteksi cepat, dan pemulihan otomatis, yang cocok untuk platform real-time seperti chat, routing panggilan, notifikasi, dan layanan koordinator.
Dalam konteks ini, “real-time” biasanya berarti soft real-time:
Ini bukan tentang batas waktu mikrodetik, melainkan menghindari jeda, spiral, dan kegagalan beruntun.
Concurrency-by-default berarti menyusun sistem sebagai banyak pekerja kecil dan terisolasi daripada beberapa komponen besar dan saling terkait erat.
Setiap pekerja menangani tanggung jawab sempit (sesi, perangkat, panggilan, loop retry), yang mempermudah penskalaan dan isolasi kegagalan.
Lightweight processes adalah pekerja independen kecil yang dapat Anda buat dalam jumlah besar.
Secara praktis, berguna karena:
Message passing adalah koordinasi dengan mengirim pesan daripada berbagi keadaan yang dapat diubah.
Ini membantu mengurangi kelas bug konkurensi (seperti race condition) karena setiap pekerja memiliki data internalnya sendiri; pihak lain hanya bisa meminta perubahan melalui pesan.
Back-pressure terjadi ketika pekerja menerima pesan lebih cepat daripada yang bisa diproses, sehingga mailbox-nya membesar.
Cara praktis menanganinya termasuk:
“Let it crash” berarti: jika seorang pekerja berada dalam keadaan tidak valid atau tak terduga, ia harus gagal cepat daripada berjalan pincang.
Pemulihan ditangani secara struktural (melalui supervisi), sehingga alur kode lebih sederhana dan pemulihan lebih dapat diprediksi — dengan catatan restart aman dan cepat.
Pohon supervisi adalah hirarki di mana supervisor memantau worker dan me-restart mereka sesuai aturan.
Daripada menyebarkan logika pemulihan ad‑hoc, Anda memusatkannya:
OTP adalah sekumpulan pola standar (behaviours) dan konvensi yang membuat sistem Erlang dapat dioperasikan dalam jangka panjang.
Blok bangunan umum termasuk:
gen_server untuk worker berumur panjang yang menyimpan state dan menangani request satu per satusupervisor untuk kebijakan restart otomatisapplication untuk mendefinisikan cara service dimulai, dihentikan, dan dimasukkan ke dalam releaseAnda bisa menerapkan prinsip yang sama di stack lain dengan menjadikan kegagalan dan pemulihan sebagai prioritas:
Untuk lebih lanjut, postingan ini merujuk ke panduan di dan detail implementasi di .
Keuntungannya: lifecycle yang dibagi dan dipahami bersama alih-alih framework custom tiap proyek.