Monolith vs Microservices: Gue Pernah Salah Pilih, Ini Pengalaman Gue

Gue inget 2021. Startup pertama gue growing. Monolith Rails app kita udah 50.000 lines. Deploy makin lama, test suite 20 menit, satu team ngerjain codebase yang sama bikin conflict mulu. Gue baca article Netflix, Spotify, Uber - semua bilang: "split jadi microservices, jadi scalable." Gue yakim.

3 bulan ngelakuin migrasi. Dipecah jadi 8 service. Hasilnya? Production jadi 3x lebih ribet, bukan 3x lebih cepet. Latency naik, debugging jadi nightmare, on-call alarm bunyi tiap malam. Tim yang tadinya 6 orang butuh tambah 2 DevOps cuma buat ngurusin kubernetes cluster.

Filosofi yang gue pelajarin keras-keras: microservices bukan upgrade teknis. Microservices itu jawaban atas masalah organisasi, bukan masalah teknis. Kalau lo mikir microservices = "lebih modern," lo bakal salah jalan kayak gue.

---

Analogi yang Bikin Masalah Jelas

Bayangin lo punya restoran.

Monolith = satu dapur besar. Semua chef masak di tempat yang sama, share kompor, share bahan, share kulkas. Kalau lagi rame, semua orang ribet. Tapi kalau ada masalah - kompor rusak - semua tau, semua fix bareng. Koordinasi gampang karena orang-orangnya di tempat yang sama.

Microservices = tiap menu punya dapur sendiri. Dapur pasta, dapur steak, dapur dessert. Tiap dapur independen - punya staf sendiri, stok sendiri, kompor sendiri. Kalau dapur pasta kewalahan, dapur steak gak terpengaruh. Tapi kalau customer pesan paket komplit (appetizer + main + dessert), butuh 3 dapur koordinasi. Waiter harus bolak-balik. Billing ribet. Kalau satu dapur gagal kirim, seluruh pengalaman customer rusak.

Itu masalah microservices: koordinasi antar service sering kali lebih mahal daripada kompleksitas yang lo pecah.

---

Kenapa Banyak yang Buru-Buru Migrasi

1. Hype "Netflix nglakuin ini."

Netflix split jadi ratusan microservices. Terus semua startup mikir "ini cara yang bener." Padahal Netflix punya 8000+ engineer. Tim lo 6 orang. Skalanya beda 1000x. Yang cocok buat Netflix belum tentu cocok buat lo.

2. "Biar bisa scale independently."

Argumen klasik: "kalau traffic auth service naik 10x, cuma auth yang di-scale, bukan seluruh app." Bunyinya masuk akal. Tapi praktiknya: 90% startup gak pernah nyampe skala di mana ini jadi bottleneck. Lo scale-kan satu monolith EC2 instance, selesai. Belum butuh microservices.

3. Conway's law yang gak disadari.

Melvin Conway, 1967: "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations." Artinya: arsitektur lo bakal ngikutin struktur tim lo. Tim lo 5 orang? Monolith bakal natural. Tim lo 50 orang di 5 tim cross-functional? Microservices masuk akal. Banyak yang migrasi teknologi dulu, padahal masalahnya struktur tim.

---

Kapan Monolith Menang

1. Tim kecil (< 10 engineer).

Microservices butuh overhead: API gateway, service mesh, distributed tracing, CI/CD per service. 1 DevOps bisa handle 1 monolith. 1 DevOps kewalahan handle 8 microservices.

2. Early-stage startup.

Lo belum tau produk-market fit lo. Requirement berubah cepet. Monolith gampang refactor. Microservices tiap perubahan cross-service = deploy koordinasi + backward compat.

3. Domain lo belum jelas boundary-nya.

Microservices butuh bounded context (konsep DDD). Lo harus tau: "fitur A concern-nya apa, fitur B concern-nya apa, boundary-nya di mana." Kalau lo belum tau, pecah duluan = bakal salah boundary, migrasi ulang 2x lebih sakit.

4. Kompleksitas operasional belum terasa.

Monolith 50.000 lines sebenarnya masih kecil. Shopify jalan dengan monolith rails sampai 1 juta+ lines. Basecamp juga monolith. Monolith gak "skala" itu mitos.

---

Kapan Microservices Benar-benar Needed

1. Tim udah gede (40+ engineer) dan cross-functional.

Tim payments 8 orang, tim inventory 10 orang, tim search 6 orang. Mereka gak harusganggu satu sama lain. Service boundary = team boundary. Deploy independen. Release cycle cepet.

2. Skala beban beda-beda banget.

Auth service 10.000 RPS, billing service 100 RPS. Beda 100x. Scale-up monolith boros - lo bayar RAM/CPU buat service yang gak butuh. Microservices = scale tiap service sesuai kebutuhan.

3. Domain udah mature.

Kalo domain lo udah jalan 5 tahun, boundary udah stabil, perubahan jarang cross-service. Bisa dipecah dengan percaya diri.

4. Ada kebutuhan isolasi failure.

Payment service down? User masih bisa browse catalog. Search down? Checkout masih jalan. Monolith gak bisa ngelakuin ini - satu bug bisa crash semua.

---

Yang Gue Pelajarin dari Migrasi Gagal

1. Distributed monolith adalah neraka.

Lo pecah jadi 8 service, tapi mereka tetep saling call, tight coupling, deploy bareng. Itu bukan microservices - itu "distributed monolith." Lo dapet kompleksitas microservices tanpa dapet benefit-nya. Lebih parah dari monolith biasa.

2. Data consistency jadi masalah baru.

Monolith: User.where(active: true).count - 1 query. Microservices: user service + order service + billing service masing-masing punya DB sendiri. Mau tau "user aktif yang udah bayar bulan ini"? Butuh API call 3 service, atau data duplication, atau event sourcing. Latency naik 5x.

3. Observability harus naik level.

Monolith: 1 log file. Microservices: 8 log files di 8 server. Tanpa distributed tracing (Jaeger, Zipkin), debugging production incident = menebak-nebak. Lo butuh correlation ID, structured logging, alerting per service. Itu investasi besar.

4. Network bukan free.

API call antar service: 5-20ms latency. Function call dalam monolith: <1ms. 10 service call berantai = 100ms latency tambahan. Lo baru sadar pas user complaint "app lemot."

---

Quick Comparison

| | Monolith | Microservices |
|---|---|---|
| Setup complexity | Rendah | Tinggi (API gateway, service mesh, observability) |
| Deploy speed | Lambat (full app) | Cepat per service |
| Scalability | Vertikal + horisontal terbatas | Horisontal per service |
| Debugging | Gampang (1 process, 1 log) | Susah (distributed tracing needed) |
| Data consistency | Gampang (1 DB, transaksi) | Susah (eventual consistency, saga) |
| Tim size ideal | < 10-15 engineer | 40+ engineer di multiple tim |
| Failure isolation | Lemah (1 bug crash semua) | Kuat (service failure isolated) |
| Best for | Startup, MVP, domain baru | Mature product, large org |

---

Yang Sering Disalahpahami

"Microservices itu modern, monolith itu legacy." - Salah. Monolith modular (arsitektur DDD dalam satu deploy unit) adalah pilihan yang valid dan modern. Github, Shopify, Basecamp - monolith dengan jutaan user.

"Pake microservices = scalable." - Tidak otomatis. Lo bisa scale monolith vertikal (instance gede) atau horisontal (multiple instance + load balancer). Microservices bukan prasyarat scale.

"Monolith gak bisa dipecah kalau udah gede." - Bisa. Lihat "modular monolith" pattern - pecah jadi module dengan boundary jelas dalam satu codebase. Bisa migrate ke microservices kapan aja kalau udah mature.

"Microservices bikin tim lebih produktif." - Tergantung. Tim kecil bakal kewalahan. Tim gede dengan boundary jelas bakal lebih produktif. Tergantung org structure, bukan teknologi.

---

Penutup yang Jujur

Gue migrate ke microservices 2021 dan balik ke monolith modular 2023. 2 tahun wasted di kompleksitas yang gak harus ada. Tim kita 8 orang, kita gak butuh 8 service. Yang kita butuh: boundary yang jelas dalam 1 codebase, deployment pipeline yang solid, dan discipline ngoding.

Filosofi yang sebenarnya: microservices itu jawaban atas masalah organisasi, bukan masalah teknologi. Kalau tim lo kecil dan sering conflic di codebase, solusinya bukan pecah jadi microservices. Solusinya: code review lebih strict, module boundary lebih jelas, test yang nge-cover regression. Pecah organisasi dulu kalau perlu - tim yang cross-functional, bukan tim per layer.

Mau microservices? Pastiin: (1) tim udah gede, (2) domain boundary udah jelas, (3) lo siap invest di observability + DevOps. Kalau salah satu gak ada, monolith modular selalu lebih baik.

Pilih arsitektur sesuai masalah lo, bukan sesuai yang lagi hype di Medium.