Belajar Backend Developer - Microservices & Modular Monolith

#Pendahuluan

Di episode 0-11 kalian sudah membangun semua keterampilan inti backend: API, database, auth, testing, caching, queue, dan observability. Sekarang tibalah pertanyaan arsitektur yang paling sering diperdebatkan: monolith atau microservices? Jawaban yang naif adalah "microservices pasti lebih baik" — padahal keputusan ini punya konsekuensi besar dan sering disalahpahami.

Mengapa ini penting? Karena arsitektur menentukan cara tim bekerja, cara sistem dideploy, dan cara data dibagi. Microservices yang salah justru menghasilkan sistem yang lebih lambat dan lebih sulit dirawat dibanding monolith yang rapi. Episode ini membahas tiga pendekatan — monolith, modular monolith, dan microservices — plus tren 2026 yang pragmatis: macrolith.

#Tiga Pendekatan

#1. Monolith Klasik

Satu aplikasi, satu codebase, satu deployment. Semua fitur — produk, order, payment, user — hidup di dalamnya.

• Kelebihan: sederhana, mudah di-debug, deployment satu tempat, tanpa overhead jaringan antar service.
• Kekurangan: codebase membesar, deploy satu fitur = deploy semua, scaling per-fitur sulit.

#2. Modular Monolith

Satu aplikasi, tapi dipisahkan rapi menjadi modul yang mandiri. Ini langkah pertama yang hampir selalu benar — dan sering kali cukup.

shop-api/
├── src/
│   ├── modules/
│   │   ├── catalog/        # produk & stok
│   │   │   ├── routes.ts
│   │   │   ├── service.ts
│   │   │   └── repository.ts
│   │   ├── order/          # order & pembayaran
│   │   │   ├── routes.ts
│   │   │   ├── service.ts
│   │   │   └── repository.ts
│   │   ├── identity/       # user, auth
│   │   └── notification/   # email worker
│   ├── shared/             # logger, http client, error handler
│   └── app.ts

• Kelebihan: seluruh keuntungan monolith + batas antar modul yang jelas, mudah di-refactor jadi service terpisah nanti.
• Kekurangan: tetap satu deployment; modul yang "bocor" (saling import langsung) merusak batas.

#3. Microservices

Setiap domain menjadi service terpisah — codebase, deployment, dan database sendiri — berkomunikasi lewat jaringan (HTTP/gRPC, episode 13) atau event (episode 22).

• Kelebihan: skala dan deploy independen per domain, tim bisa bergerak sendiri, isolasi kegagalan.
• Kekurangan: kompleksitas distribusi (jaringan, konsistensi data, observability lintas service), overhead operasional besar, debugging menyebar.

#Aturan Emas: Monolith Dulu, Pisahkan Nanti

Kesalahan paling mahal di industri bukan memilih monolith — melainkan microservices premature: memecah sistem sebelum memahami domain dan batas antar modulnya. Aturan yang paling pragmatis:

1. Mulai dengan modular monolith — batas modul yang jelas, satu deployment.
2. Pisahkan saat ada alasan nyata, bukan "kelihatan modern": tim berbeda butuh deploy sendiri, beban per-modul sangat berbeda, atau skalabilitas independen diperlukan.
3. Setiap pemisahan harus punya biaya yang bisa dipertanggungjawabkan.

#Tren 2026: Macrolith yang Pragmatis

Istilah yang populer di 2026 adalah macrolith — pendekatan tengah yang pragmatis. Prinsipnya: sebagian besar sistem tetap satu aplikasi (modular), dan hanya bagian yang benar-benar perlu yang dipisah sebagai service.

Contoh nyata pada toko online kita:

• Modular monolith: catalog, order, identity, dan notification dalam satu aplikasi.
• Service terpisah: komponen yang butuh skala berbeda — misalnya email worker dipindah ke service sendiri karena lonjakan beban tidak sinkron dengan API, atau AI service (episode 23) yang memakai runtime berbeda.

Macrolith mengakui bahwa bukan semua domain layak microservices — hanya yang punya alasan konkret. Ini meniadakan overhead microservices penuh tanpa menyerah pada skala yang dibutuhkan.

#Kapan Benar-Benar Microservices?

Empat alasan yang sah untuk memecah:

1. Skala independen — satu modul butuh 100 instance, modul lain cukup 2.
2. Tim besar — lebih dari ~50 engineer; rilis per tim tanpa menabrak satu sama lain.
3. Batasan teknologi — satu modul butuh runtime berbeda (Go untuk performa, Python untuk AI).
4. Isolasi kegagalan & compliance — kegagalan satu domain tidak menjatuhkan seluruh sistem, atau data perlu diisolasi (episode 19).

Jika tidak ada satu pun alasan ini di tim kalian, modular monolith hampir pasti cukup.

#Menjaga Batas Modul Tetap Sehat

Baik modular monolith maupun microservices bergantung pada batas modul yang disiplin. Tiga aturan:

1. Data milik domain — tabel orders hanya boleh diakses modul order; modul lain lewat API/event.
2. Tanpa import lintas modul — catalog/service.ts tidak pernah memanggil order/repository.ts langsung.
3. Kontrak eksplisit — komunikasi antar modul lewat fungsi/interface yang didokumentasikan, sehingga saat dipisah jadi service, perubahan hanya di lapisan komunikasi.

Contoh batas yang bocor — dan yang benar:

BOLEH:    order/service.ts → notification/sendEmail()  (via interface)
BOLEH:    order → kafka publish "order.created"
JANGAN:   order/repository.ts → query tabel notification.email_queue

#Common Pitfalls

#Microservices Premature

Memecah tanpa alasan = kompleksitas tanpa manfaat. Mulai modular monolith.

#Berbagi Satu Database antar Service

Melanggar isolasi data — mematikan alasan utama microservices.

#HTTP Sinkron Berantai

API → service A → service B → service C secara sinkron membuat latency bertumpuk dan satu kegagalan meruntuhkan rantai. Alihkan dengan event/queue (episode 10, 22).

#Distribusi Tanpa Observability

Service tersebar tanpa tracing (episode 11) = debugging mimpi buruk. Tracing bukan opsional saat sistem terdistribusi.

#Penutup

Episode 12 membedah keputusan arsitektur: monolith klasik, modular monolith dengan batas modul yang disiplin, dan microservices untuk alasan yang konkret — plus tren 2026, macrolith, yang memisahkan hanya yang benar-benar perlu.

Inti yang harus dibawa pulang:

• Mulai modular monolith, pisahkan saat ada alasan nyata.
• Empat alasan sah microservices: skala independen, tim besar, batasan teknologi, isolasi.
• Jangan berbagi satu database antar service — itu monolith yang dideploy terpisah.
• Jaga batas modul: data milik domain, tanpa import lintas modul, kontrak eksplisit.
• Tren 2026: macrolith pragmatis — satu aplikasi modular, hanya yang perlu dipisah.

Di episode 13 selanjutnya kita akan menyatukan akses antar layanan: API gateway & gRPC — gateway untuk routing dan rate limiting, serta gRPC untuk komunikasi service-to-service yang efisien. Sampai jumpa di episode 13!