Monolith adalah satu aplikasi yang memuat semua fitur, jalan sebagai satu proses, dan di-deploy sekaligus. Microservices memecah aplikasi jadi banyak service kecil yang masing-masing punya kode, database, dan jadwal deploy sendiri, lalu saling bicara lewat jaringan. Bayangin warung makan dengan satu dapur dibanding food court. Di warung, semua koki di satu dapur: minta sambal tinggal teriak, tapi kalau dapurnya kebakaran, warungnya tutup. Di food court, tiap kios punya dapur dan kasir sendiri: kios bakso bisa renovasi tanpa food court tutup, tapi pesan bakso plus es teh berarti antre di dua kios.
🧪 Tebakan cepat: checkout TiketNada di versi microservices melewati 5 service, dan tiap service hidup 99,9% dari waktu. Berapa persen checkout yang bisa sukses: 99,9%, 99,5%, atau 95%? Tebak dulu, jawabannya ada di bagian "Satu checkout, lima panggilan jaringan".
Monolith: satu aplikasi, satu deploy
TiketNada mulai sebagai monolith: satu aplikasi app dengan modul akun, konser, order, bayar, dan tiket, plus satu database PostgreSQL. Modul order memanggil modul bayar sebagai function call biasa di proses yang sama, butuh kurang dari satu mikrodetik dan gak bisa "hilang di jalan".
Monolith yang rapi disebut modular monolith: tiap modul punya folder, aturan, dan tabelnya sendiri, dan modul lain cuma memanggil function yang memang dibuka untuknya. Tetap satu deploy, tapi batasnya jelas, jadi kelak gampang dipisah.
Microservices: banyak service kecil
Di versi microservices, tiap modul jadi service sendiri: proses sendiri, database sendiri, di-deploy sendiri, biasanya dipegang satu tim. order gak boleh membaca tabel milik bayar; dia harus bertanya lewat API (HTTP atau gRPC) atau mengirim pesan lewat message queue. Untungnya: tiap service bisa di-deploy dan di-scale sendiri. Harganya: tiap pertanyaan antarservice sekarang lewat jaringan.
Satu checkout, lima panggilan jaringan
Satu checkout menyentuh 5 bagian: akun (cek login), konser (cek kursi), order (buat pesanan), bayar (potong kartu), dan tiket (terbitkan e-tiket). Angka model contoh: satu panggilan jaringan di dalam data center menambah 5 ms, dan tiap service (atau monolith-nya) hidup 99,9% dari waktu.
| Monolith | Microservices | |
|---|---|---|
| Cara memanggil | 5 function call | 5 panggilan jaringan |
| Tambahan waktu | hampir 0 ms | 5 × 5 ms = 25 ms |
| Checkout sukses | 99,9% (satu aplikasi) | 0,999⁵ = 99,50% |
| Gagal per 10.000 checkout | 10 | 50 |
| Checkout gak bisa jalan per bulan | 43,2 menit | 216 menit, sekitar 3,6 jam |
Checkout sukses cuma kalau kelima service hidup, jadi peluangnya dikalikan: 0,999 × 0,999 × 0,999 × 0,999 × 0,999 = 0,995. Jawaban tebakannya 99,5%: lima kali lebih banyak checkout gagal dibanding monolith, padahal tiap service sama andalnya.
// TiketNada, model contoh: ongkos satu checkout
const arsitektur = "microservices"; // "monolith" atau "microservices"
const dilewati = ["akun", "konser", "order", "bayar", "tiket"];
const HOP_MS = 5; // tambahan waktu 1 panggilan jaringan
const UPTIME = 0.999; // tiap service hidup 99,9% dari waktu
const remote = arsitektur === "microservices";
const tambahanMs = remote ? dilewati.length * HOP_MS : 0;
const sukses = remote ? UPTIME ** dilewati.length : UPTIME;
console.log("Tambahan waktu:", tambahanMs, "ms"); // 25 ms
console.log("Checkout sukses:", (sukses * 100).toFixed(2) + "%"); // 99.50%
console.log("Gagal per 10.000:", Math.round((1 - sukses) * 10000)); // 50
dilewatiadalah daftar service yang disentuh satu checkout. Tambah satu nama, ongkosnya ikut naik.dilewati.length * HOP_MS: tiap service yang dipanggil berurutan menambah 5 ms.UPTIME ** dilewati.length: peluang semuanya hidup bersamaan. Ini yang membuat rantai panjang rapuh.- Di monolith,
suksescumaUPTIME: satu aplikasi, satu peluang mati.
Deploy: siapa menunggu siapa
Sekarang dari sisi tim. Misalkan tiap tim deploy sekali sehari, dan perubahan satu tim punya peluang 5% membawa bug yang membuat deploy dibatalkan (model contoh). Di monolith, perubahan semua tim ikut satu deploy, jadi deploy bersih hanya kalau semua tim bersih: 0,95 pangkat jumlah tim.
| Jumlah tim | Monolith: deploy bersih | Microservices: deploy bersih per tim |
|---|---|---|
| 1 | 95% | 95% |
| 3 | 85,7% | 95% |
| 10 | 59,9% | 95% |
Dengan 10 tim di satu monolith, 4 dari 10 deploy batal gara-gara bug orang lain. Di microservices, tim bayar bisa deploy tanpa menunggu tim konser. Itu sebabnya microservices sering disebut solusi untuk organisasi yang besar, bukan untuk kode yang lambat.
Kalau satu bagian crash
Misalkan modul tiket bocor memori sampai prosesnya mati. Di monolith, proses yang mati itu satu-satunya proses, jadi seluruh TiketNada ikut mati, halaman konser juga. Di microservices, cuma service tiket yang mati: orang masih bisa melihat konser, dan checkout gagal di langkah e-tiket saja. Ini fault isolation: kerusakan satu bagian gak menjalar ke semuanya.
Kapan pilih yang mana
- Monolith (sebaiknya modular): tim kecil, produk masih early-stage, domain belum jelas, kompleksitas belum tinggi. Mengubah batas modul di satu kode jauh lebih murah daripada memindah data antarservice.
- Pisahkan satu atau dua service: satu bagian punya kebutuhan beda jelas, misalnya
bayaryang harus terisolasi, atau bagian yang butuh di-scale 50 kali saat war tiket. - Microservices: banyak tim yang butuh deploy sendiri-sendiri, domain sudah jelas batasnya, dan tim sanggup membayar ongkos operasionalnya.
Martin Fowler menyebutnya Monolith First: mulai dari monolith yang rapi, pecah saat ada kebutuhan nyata.
Harga tambahan microservices
Begitu service saling bicara lewat jaringan, kamu butuh perlengkapan baru:
- Service discovery: cara service menemukan alamat service lain, karena instance-nya datang dan pergi.
- Service mesh: lapisan infrastruktur yang menangani komunikasi antarservice, yaitu service discovery, load balancing, retry dan circuit breaking, dan observability. Biasanya berupa proxy kecil (sidecar) di samping tiap service, jadi kode service gak perlu mengurusnya. Dibahas di lesson Service Mesh Basics.
- Distributed tracing: satu ID yang ikut request melewati semua service, supaya kelihatan service mana yang lambat (lesson Monitoring dan Logging).
- Data per service: gak ada lagi JOIN antartabel milik service lain, dan transaksi yang menyentuh dua service butuh pola seperti saga.
Detail cara membangun dan men-deploy-nya ada di lesson Microservices Architecture (track DevOps).
Pindah pelan-pelan: Strangler Fig
Kalau monolith memang harus dipecah, jangan menulis ulang semuanya lalu ganti dalam satu peluncuran besar. Pakai Strangler Fig pattern: ekstrak fitur satu per satu ke service baru sambil monolith tetap berjalan. Traffic untuk fitur itu dialihkan ke service baru secara bertahap, dan monolith mengecil sampai akhirnya bisa dimatikan. Langkah lengkapnya ada di lesson Monolith to Microservices.
⚠️ Jebakan yang sering ketemu
- Microservices terlalu dini. Tim 4 orang dengan 12 service menghabiskan waktunya mengurus jaringan, deploy, dan monitoring, bukan fitur.
- Distributed monolith. Service-nya dipisah tapi masih berbagi satu database dan harus di-deploy bersamaan. Dapat ongkos jaringan microservices, tanpa kebebasan deploy-nya.
- Rantai panggilan sinkron yang panjang. Tiap service tambahan di jalur request menambah waktu dan mengalikan peluang gagal. Pekerjaan yang gak perlu ditunggu (kirim e-tiket, email) pindahkan ke message queue.
- Butuh JOIN antarservice terus-menerus. Tanda batas service-nya salah. Data yang selalu dibaca bersama mungkin memang satu service.
TL;DR: Monolith = satu aplikasi, satu proses, satu deploy; modul saling memanggil lewat function call yang hampir gratis. Microservices = banyak service dengan kode, database, dan deploy sendiri, yang bicara lewat jaringan. Harganya bisa dihitung: checkout yang melewati 5 service masing-masing 99,9% hanya sukses 0,999⁵ = 99,5%, dan menambah 5 × 5 ms. Untungnya: tim deploy sendiri-sendiri (10 tim di satu monolith cuma 59,9% deploy bersih, di microservices 95% per tim) dan crash satu service gak mematikan semuanya. Mulai dari modular monolith saat tim kecil dan produk masih early-stage (Monolith First), pecah saat ada kebutuhan nyata, dan pecah bertahap dengan Strangler Fig. Microservices membawa service discovery, service mesh (lapisan infrastruktur untuk komunikasi antarservice), dan distributed tracing.
