Microservices vs Monolith: Budi Buka Warung Padang Raksasa

Bayangin Budi Buka Warung Padang...

Bayangin Budi bikin Warung Padang. Di warung ini, cuma ada Satu Dapur Raksasa dan Satu Koki (Budi). Budi yang masak rendang, Budi yang masak ayam pop, Budi juga yang bikin es teh. Kalau pelanggannya cuma 10 orang, sistem ini lancar jaya.

Tapi tiba-tiba warung Budi viral di TikTok! Ada 1.000 orang antre. Budi kelabakan di dapur. Parahnya lagi, suatu hari kompor untuk masak rendang meledak, memicu kebakaran kecil di dapur. Seluruh Warung Padang Budi terpaksa ditutup! Orang yang cuma mau beli Es Teh pun ikut kena imbas gak bisa beli.

Masalahnya: Arsitektur Monolith Itu Kaku

Di dunia Backend, warung Budi disebut arsitektur Monolith. Semua fitur (Login, Pembayaran, Keranjang, Chat) ditulis dalam satu folder proyek Node.js besar dan dijalankan di satu Server.

• Kalau fitur Chat-nya kehabisan RAM, seluruh aplikasi (termasuk fitur Pembayaran) akan ikut mati!
• Kalau kamu mau update warna tombol di halaman Profil, kamu harus men-deploy dan me-restart seluruh server raksasa tersebut.

Nah, Di Sinilah 'Microservices' Masuk!

Siti (seorang Arsitek IT) menyarankan Budi mengubah warungnya menjadi Pujasera (Food Court / Microservices).

• Budi memecah warungnya jadi 3 stan terpisah: Stand Rendang, Stand Ayam, dan Stand Minuman. Masing-masing dijaga oleh koki yang berbeda (Server terpisah).
• Jika kompor Stand Rendang (Server Pembayaran) meledak, Stand Minuman (Server Chat) tetap buka dan jualan dengan lancar! Pelanggan cuma gak bisa beli rendang, tapi masih bisa beli es teh.
• Jika Stand Ayam tiba-tiba antreannya panjang banget, Budi cukup menyewa 1 koki tambahan KHUSUS untuk Stand Ayam saja (Targeted Scaling), tanpa perlu memperbesar Stand Minuman.

Intinya: Monolith itu bagus dan murah untuk *Startup* yang baru lahir. Tapi saat aplikasimu sekelas Tokopedia atau Gojek, memecah belah sistem menjadi Microservices adalah satu-satunya cara agar aplikasimu tidak hancur lebur menahan beban.