sumber pinterest : https://pin.it/6gLlRMYoj

MADILOG: Ketika Filsafat Lokal Menjawab Dilema Arsitektur Software Modern

Pelajaran dari Tan Malaka yang tidak pernah diajarkan di bootcamp mana pun

Dua tahun lalu, saya membuat keputusan arsitektur yang malu saya ceritakan.

Saya sedang membangun sistem baru — belum ada satu user pun yang onboard, tim hanya saya sendiri — dan saya sudah mulai setup message broker, merancang event-driven architecture, memisahkan service-service kecil yang “mungkin nanti akan dibutuhkan.”

Tiga bulan kemudian, saya menghabiskan lebih banyak waktu untuk debugging infrastruktur daripada membangun fitur. Sistem yang saya banggakan itu — tidak pernah sampai ke tangan pengguna dalam kondisi layak.

Saya tidak kekurangan skill teknis. Yang saya kekurangan adalah cara berpikir yang benar sebelum memilih teknologi.

Dan ironisnya, jawabannya sudah ada jauh sebelum internet ada. Ditulis oleh seorang revolusioner Indonesia bernama Tan Malaka, dalam sebuah buku berjudul MADILOG — diselesaikan dalam 720 jam, selama delapan bulan, antara 15 Juli 1942 hingga 30 Maret 1943, di tengah pendudukan Jepang.

Apa Itu MADILOG?

MADILOG adalah akronim dari Materialisme, Dialektika, Logika — ditulis oleh Tan Malaka (dengan nama pena Iljas Hussein) dan pertama kali diterbitkan secara resmi pada 1951.¹

Tan Malaka menulis buku ini untuk satu tujuan: membebaskan cara berpikir masyarakat Indonesia dari apa yang ia sebut “logika mistika” — cara pandang yang tidak berakar pada fakta dan realitas, melainkan pada asumsi, takhayul, dan kebiasaan yang tidak pernah dipertanyakan.

Saya membaca ini dan satu kalimat langsung terasa sangat familiar:

Kebenaran harus berdasarkan kondisi nyata, bukan pada ide abstrak.

Ini bukan tentang software. Tapi ini persis masalah yang saya hadapi — dan yang dihadapi banyak developer setiap hari.

Masalah Besar Developer Saat Ini

Perhatikan pola yang sering terjadi:

Seseorang baca artikel tentang arsitektur Netflix. Lalu langsung menerapkannya ke project yang baru punya 50 user.

Seseorang ikut conference, pulang dengan semangat clean architecture level enterprise. Lalu diterapkan ke CRUD sederhana yang deadline-nya minggu depan.

Ini bukan masalah kemampuan. Ini masalah framework berpikir — atau lebih tepatnya, ketiadaan framework berpikir sebelum memilih teknologi.

Martin Fowler, salah satu tokoh paling berpengaruh dalam software architecture, pernah menulis observasi yang sering diabaikan:²

“Almost all the successful microservice stories have started with a monolith that got too big and was broken up. Almost all the cases where I’ve heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.” — Martin Fowler, MonolithFirst (martinfowler.com, 2015)

Fowler menulis ini pada 2015. Satu dekade berlalu, pola yang sama masih berulang.

MADILOG menawarkan penjelasan mengapa — dan cara keluarnya.

1. Materialisme — Mulai dari Realitas, Bukan Tren

Materialisme dalam MADILOG berarti: kebenaran harus berakar pada kondisi nyata, bukan pada gagasan yang terlepas dari konteks.

Tan Malaka menulis buku ini karena melihat bangsa yang mengambil keputusan besar berdasarkan kepercayaan yang tidak pernah diuji dengan fakta. Dalam software, ekuivalennya adalah: mengambil keputusan arsitektur berdasarkan tren, bukan berdasarkan kondisi nyata sistem.

Sebelum memilih arsitektur apapun, pertanyaan yang harus dijawab terlebih dahulu:

• Berapa jumlah user sekarang — bukan yang mungkin akan datang?
• Berapa orang di tim?
• Seberapa kompleks masalahnya hari ini, bukan enam bulan ke depan?

Sistem yang saya bangun dua tahun lalu itu — kalau saya jujur menjawab pertanyaan-pertanyaan di atas, jawabannya sederhana: monolith biasa sudah cukup.

Fowler menegaskan hal yang sama dalam prinsip Monolith First-nya: mulai dari yang sederhana, pecah hanya ketika tekanan nyata muncul.

Sistem kecil tidak butuh arsitektur besar. Arsitektur harus mengikuti realitas, bukan ego teknis.

2. Dialektika — Sistem Harus Bisa Berkembang

Dialektika dalam MADILOG berbicara tentang perubahan yang terjadi melalui kontradiksi dan interaksi — tidak ada yang statis, semua bergerak dan bertransformasi karena tekanan dari dalam maupun luar.

Dalam software: tidak ada sistem yang akan tetap seperti hari pertama dibangun.

Evolusinya hampir selalu mengikuti pola yang sama:

1. Awal → monolith sederhana, cepat, mudah dipahami
2. User bertambah → muncul bottleneck di titik tertentu
3. Bottleneck itu menjadi kontradiksi yang tidak bisa diabaikan
4. Sistem merespons → service terpisah, queue masuk, arsitektur berevolusi

Sam Newman, dalam bukunya Building Microservices (O’Reilly, edisi kedua 2021), senada dengan Fowler: microservices baru masuk akal ketika batas antar domain sudah terbukti stabil — sesuatu yang hampir tidak mungkin diketahui sebelum sistem berjalan.³

Yang berbahaya adalah dua ekstrem:

• Membangun monolith yang tidak dirancang untuk berubah
• Atau membangun microservices sebelum kontradiksinya benar-benar muncul

Dialektika mengajarkan: respons terhadap tekanan nyata, bukan antisipasi spekulatif.

Sistem yang tidak dirancang untuk berubah akan hancur saat berkembang. Tapi sistem yang terlalu dini dipecah, akan hancur sebelum sempat berkembang.

3. Logika — Struktur yang Konsisten dan Tidak Kontradiktif

Logika dalam MADILOG menekankan berpikir runtut, konsisten, dan bebas dari kontradiksi internal. Tan Malaka menggunakannya sebagai antitesis dari logika mistika — cara berpikir yang tidak konsisten dan tidak bisa diverifikasi.

Dalam software, logika yang tidak konsisten muncul bukan dalam bentuk mistika, tapi dalam bentuk:

• Validasi yang tersebar di controller, model, dan middleware sekaligus — dengan aturan yang saling bertentangan
• Business logic yang campur aduk dengan database query
• Alur data yang tidak bisa di-trace dari satu ujung ke ujung lain

Robert C. Martin dalam Clean Architecture: A Craftsman’s Guide to Software Structure and Design (Prentice Hall, 2017) menyebut prinsip ini sebagai Separation of Concerns — memisahkan bagian-bagian sistem berdasarkan alasan dan waktu perubahannya.⁴

Implementasinya tidak harus rumit:

• Controller hanya handle request dan response
• Service handle business logic
• Repository handle akses data

Ini bukan tentang framework mana yang dipakai. Ini tentang apakah alurnya konsisten dan bisa dipercaya — apakah seseorang yang baru bergabung ke tim bisa membaca kode dan memahami mengapa sesuatu ada di tempat itu.

Sistem yang tidak logis akan sulit dipahami, sulit diuji, dan sulit dikembangkan — tidak peduli secanggih apa teknologinya.

Menghubungkan Ketiganya

MADILOG Manifestasi dalam Software Materialisme Mulai dari monolith, sesuai skala dan kondisi nyata Dialektika Evolusi ke microservices/event-driven saat bottleneck datang Logika Clean architecture, separation of concerns, konsistensi struktur

Tapi yang paling penting untuk dipahami:

MADILOG bukan tentang teknologi mana yang dipilih. Ini tentang bagaimana memilih — dan kapan.

Pendekatan yang Lebih Tepat

Tahap 1 — Materialisme Bangun monolith sederhana. Fokus ke fitur inti yang benar-benar dibutuhkan user sekarang. Tahan godaan untuk mengantisipasi scale yang belum ada.

Tahap 2 — Dialektika Ketika bottleneck muncul — bukan ketika kamu menduga akan muncul — mulai tambah queue, pisah service yang memang perlu dipisah. Biarkan tekanan nyata yang memandu keputusan.

Tahap 3 — Logika Saat sistem mulai kompleks, rapikan strukturnya. Ini bukan refactor karena tren, tapi karena sistem butuh konsistensi untuk bisa bertahan dan dikembangkan lebih jauh.

Penutup

Infrastruktur yang saya bangun dua tahun lalu itu akhirnya saya cabut. Diganti dengan solusi jauh lebih sederhana. Sistem berjalan lebih stabil, lebih mudah di-debug, dan tim bisa fokus ke hal yang sebenarnya penting: fitur yang berguna.

Bukan karena teknologi yang saya pilih buruk. Tapi karena kondisi nyata saya tidak membutuhkannya.

Di dunia yang penuh hype framework dan arsitektur baru setiap bulan, MADILOG mengingatkan hal yang sederhana namun sering dilupakan:

Mulai dari realitas. Pahami bahwa semuanya akan berubah. Dan berpikirlah secara konsisten.

OOP hanyalah alat. Microservices hanyalah pilihan. Arsitektur hanyalah strategi.

Tapi cara berpikir — itu fondasi dari semuanya.

Pernah punya pengalaman serupa — terlalu cepat memilih arsitektur kompleks, atau sebaliknya terlalu sederhana hingga kolaps saat scaling?

Referensi

¹ Tan Malaka, Madilog: Materialisme, Dialektika, Logika. Ditulis 15 Juli 1942–30 Maret 1943. Edisi resmi pertama: Terbitan Widjaya, Jakarta, 1951. Edisi terbaru: IRCiSoD, 2024. Tersedia juga di: marxists.org/indonesia/archive/malaka/Madilog/

² Martin Fowler, “MonolithFirst”. martinfowler.com/bliki/MonolithFirst.html. Dipublikasikan 3 Juni 2015.

³ Sam Newman, Building Microservices: Designing Fine-Grained Systems, edisi kedua. O’Reilly Media, 2021.

⁴ Robert C. Martin, Clean Architecture: A Craftsman’s Guide to Software Structure and Design. Prentice Hall (Robert C. Martin Series), 2017. ISBN: 978–0134494166.