Belajar Software Architect - Modular Monolith & Evolution

#Pendahuluan

Setelah di episode 14 kalian merancang cloud-native architecture — 12-factor, container, Kubernetes, dan serverless — pada episode ini kita kembali ke keputusan style dari episode 3 dengan kedalaman penuh: modular monolith, style yang justru mendominasi narasi industri 2026.

Ini bukan episode pengulangan. Episode 7 membahas mekanika boundary (cohesion, coupling, fitness function); kali ini kita bahas siklus hidupnya: mengapa industri yang sepuluh tahun memuji microservices mulai berbalik, bagaimana monolith modular bekerja sehari-hari di tim yang bertumbuh, dan bagaimana jalur evolusinya menuju services tanpa rewrite besar.

#Gelombang Industri yang Berbalik Arah

Beberapa kasus terkenal menandai pergeseran ini:

Perhatikan polanya dengan hati-hati: ini bukan anti-microservices. Prime Video tetap menjalankan ratusan service di tempat lain; mereka hanya menyadari satu workload tidak butuhnya. Pelajaran architect-nya: style adalah alat, bukan identitas tim.

Mengapa gelombang balik ini terjadi? Karena generasi pertama adopsi microservices membayar tagihannya: distributed debugging, biaya platform, koordinasi rilis lintas tim, dan konsistensi data yang sulit. Banyak organisasi membayar harga terdistribusi tanpa menerima manfaatnya — karena masalah mereka sebenarnya adalah boundary yang buruk, bukan deployment yang bersatu.

#Anatomi Monolith yang Benar-Benar Modular

Modular monolith ≠ monolith biasa dengan folder rapi. Bedanya ada tiga lapis disiplin:

#Lapis 1: Boundary Kode

Zona publik eksplisit dan larangan import internal (episode 7) dipaksa lewat tooling — ESLint boundaries, compiler visibility, atau module system. Tanpa enforcement otomatis, struktur folder hanyalah niat baik.

#Lapis 2: Boundary Build & Test

Tim dewasa melangkah lebih jauh: setiap modul punya suite test sendiri yang bisa dijalankan independen, dan pipeline mengeksekusi hanya test modul yang terdampak perubahan. Manfaatnya ganda: feedback cepat seperti multi-repo, tetapi tanpa biaya sinkronisasi versi antar repos.

PR menyentuh ordering + catalog?
→ jalankan test ordering, test catalog,
   plus contract-test antara keduanya
→ modul lain dilewati: CI tetap <10 menit
   walau codebase tumbuh

#Lapis 3: Boundary Data

Satu database cluster boleh, tetapi schema terpisah per modul dengan DB user berbeda-beda: user ordering secara teknis tidak bisa SELECT dari schema inventory — pelanggaran boundary data mustahil dilakukan diam-diam. Ini versi murah dari "database per service", dan jembatan migrasinya mulus: pindahkan satu schema ke instance baru tanpa menyentuh kode selain connection string.

#Komunikasi Antar Modul dalam Satu Process

Tiga pola resmi, dipilih sadar per aliran:

Kekuatan evolusi ada di pola kedua: ketika modul inventory diekstrak menjadi service, konsumennya yang sudah mendengarkan event StockReserved tidak perlu berubah — hanya transport-nya berganti dari bus in-process ke Kafka. Desain ulang minim inilah hadiah dari disiplin sejak awal.

Transaksi lintas modul tetap satu keuntungan besar monolith: reservasi stok + pembuatan order bisa satu transaksi ACID lokal. Jangan sia-siakan sebelum waktunya — saga hanya dibayar saat boundary sudah menjadi jaringan.

#Roadmap Evolusi ke Services

Evolusi yang sehat adalah pull, bukan push — ditarik oleh masalah nyata, bukan didorong ambisi diagram:

Profil scale menyimpang tajam → ekstrak modul tsb
Kebutuhan compliance/isolasi (PCI, PII)      → ekstrak
Tim ownership mulai bentrok rilis            → ekstrak
Semua profil serupa, tim masih kecil         → TAHAN

Urutan ekstraksi yang aman:

1. Paling jauh dari inti transaksi dulu — shipping/notification lebih aman daripada ordering.
2. Yang sudah event-driven dulu — konsumennya tak berubah, hanya transport.
3. Strangler pattern untuk area luas — rutekan trafik bertahap per endpoint; detail penuh di episode 24.
4. Satu modul stabilkan dulu sebelum ekstraksi berikutnya — dua migrasi paralel adalah resep insiden.

Dan setiap ekstraksi membawa checklist wajib dari episode 12: observability siap, kontrak dijaga test, saga menggantikan transaksi lintas, dan ADR baru mencatat pemicu beserta batas waktunya.

#Praktik: Roadmap Evolusi Studi Kasus

Mari susun rencana tiga tahun e-commerce kita secara eksplisit:

tahun_1:
  state: modular monolith penuh
  fokus:
    - fitness function + schema-per-module enforcement
    - in-process event bus untuk side-effects
    - observability OTel dari hari pertama
pemicu_tahun_2: [tim >15 dev, flash sale >5x proyeksi]
gelombang_ekstraksi:
  - modul: shipping
    alasan: integrasi kurir, latensi tak menentu
    transport: outbox -> kafka
  - modul: payment
    alasan: isolasi audit PCI
    catatan: scope sempit, risiko rendah
tahun_3_kandidat:
  - modul: inventory
    syarat: profil scale menyimpang (episode 11)
tahankan: [ordering, catalog]
alasan: inti transaksional ACID; pecah belakangan
       atau tidak sama sekali bila pemicu tak muncul

Catat sifat dokumen ini: ia bersyarat, bukan janji. Setiap gelombang menunggu pemicunya terukur — persis filosofi ADR-0002 dengan revisinya.

#Kesalahan Umum

• Modular monolith sebagai alasan menunda disiplin — "nanti kita rapikan" tanpa enforcement; hasilnya big ball of mud standar. Modularitas adalah kerja aktif harian.
• Ekstraksi sebagai prestasi — mengukur kemajuan arsitektur dari jumlah service; padahal service adalah biaya yang harus dibenarkan, bukan medali.
• Big-bang rewrite ke microservices — membongkar monolith sekaligus sambil fitur terus berjalan; hampir selalu berakhir tahun-tahunan. Jalurnya strangler bertahap (episode 24).
• In-process event bus yang diam-diam sinkron — implementasi bus yang memanggil listener secara langsung membuat aliran "async" sebenarnya coupled availability; sadari semantiknya atau pakai queue sungguhan.
• Lupa biaya organisasi — Conway's Law: modul yang tidak cocok struktur tim akan diperangi strukturnya sendiri. Selaraskan pemilikan sebelum mengecat diagram.

#Penutup

Inti yang harus dibawa pulang:

• Gelombang 2026 bukan anti-services, melainkan koreksi pasar: modular monolith sebagai default awal, microservices sebagai keputusan bertahap yang ditarik pemicu nyata.
• Modularitas sejati = tiga lapis: kode (enforced), build/test (per-modul), data (schema + user terpisah).
• Komunikasi antar modul sadar-pola: panggilan sinkron via public API, in-process event bus sebagai jembatan migrasi, outbox untuk yang lintas sistem.
• Evolusi ke services itu bertahap dan bersyarat: jauh dari inti dulu, yang event-driven dulu, satu per satu, strangler untuk area luas.
• Studi kasus kini punya evolution roadmap tiga tahun yang eksplisit: shipping & payment dulu, inventory menunggu pemicu scale, ordering-catalog ditahan.

Di episode 16 selanjutnya kita masuk resilience & reliability design — circuit breaker, retry dengan backoff dan jitter, bulkhead, timeout budget, hingga chaos readiness dan error budget untuk menjaga janji availability 99,95% jalur checkout kita. Sampai jumpa!