Monolit Modular vs Microservice untuk Web yang Terus Berubah

Untuk produk web yang kebutuhannya sering berubah, pilihan antara monolit modular vs microservice sebaiknya dimulai dari satu pertanyaan sederhana: apakah kompleksitas utama Anda berasal dari bisnis yang berubah cepat, atau dari skala organisasi dan integrasi yang sudah terlalu besar untuk ditangani dalam satu aplikasi?

Jawaban praktisnya sering tidak dramatis: banyak tim akan lebih cepat bergerak dengan monolit modular lebih dulu, lalu memecah sebagian domain menjadi microservice hanya ketika batas domain, beban operasional, dan kebutuhan deploy independen memang sudah jelas. Microservice bukan upgrade otomatis dari monolit; ia menukar kompleksitas internal aplikasi menjadi kompleksitas jaringan, observability, konsistensi data, dan operasi produksi.

Perubahan karakter web modern ikut mendorong dilema ini. Aplikasi web lama cenderung lebih sederhana: halaman, formulir, sedikit interaksi, dan alur backend yang relatif lurus. Web modern bergerak ke arah produk yang terus berevolusi: notifikasi real-time, integrasi pihak ketiga, workflow asinkron, personalisasi, banyak klien, analitik, serta ekspektasi rilis cepat. Kompleksitas ini bukan nostalgia terhadap web lama, melainkan penjelasan mengapa batas arsitektur menjadi makin penting ketika fitur terus berubah.

Memahami perbedaan dasarnya

Apa itu monolit modular

Monolit modular adalah satu aplikasi yang dideploy sebagai satu unit, tetapi struktur kodenya dipisahkan tegas berdasarkan domain atau modul. Contohnya: catalog, checkout, billing, identity, dan notification. Setiap modul memiliki API internal, aturan dependensi, dan idealnya tidak saling membaca tabel database secara bebas.

Kelebihan utamanya adalah kesederhanaan operasional: satu pipeline deploy, satu proses debugging end-to-end, local development lebih mudah, dan observability dasar lebih murah dibangun. Kekurangannya: jika batas modul longgar, aplikasi mudah berubah menjadi big ball of mud, yaitu kode besar yang semua bagian saling bergantung.

Apa itu microservice

Microservice memecah sistem menjadi layanan kecil yang dideploy terpisah, biasanya dengan API sinkron atau event asinkron. Setiap service idealnya memiliki tanggung jawab domain yang jelas dan data ownership sendiri.

Kelebihannya: tim bisa deploy lebih independen, isolasi kegagalan dapat lebih baik, dan domain yang benar-benar berbeda dapat berkembang dengan ritme berbeda. Kekurangannya jauh lebih mahal: koordinasi jaringan, retry, timeout, idempotency, tracing, versioning kontrak API, keamanan antar-service, dan debugging lintas service.

Trade-off teknis yang benar-benar menentukan

1. Coupling: dekat di kode, atau tersebar di jaringan

Pada monolit modular, coupling biasanya terlihat jelas di level kode: impor antar-modul, pemanggilan langsung, atau akses database lintas modul. Ini buruk jika tak dikontrol, tetapi setidaknya terlihat dan relatif mudah direfaktor.

Pada microservice, coupling sering tampak lebih rapi di permukaan karena dipisahkan service. Masalahnya, coupling bisa berpindah ke jaringan dan kontrak runtime: format event, urutan panggilan API, kebutuhan data sinkron, hingga asumsi timeout. Service terpisah tidak otomatis membuat domain terpisah.

Catatan penting: jika dua komponen harus selalu berubah bersama, selalu di-deploy bersama, dan selalu membutuhkan data yang sama dalam satu transaksi bisnis, kemungkinan besar itu belum layak dipisah menjadi microservice.

2. Batas domain lebih penting daripada jumlah service

Kesalahan umum adalah memecah sistem berdasarkan layer teknis, misalnya service untuk user, service untuk email, service untuk database access, tanpa konteks domain yang kuat. Pemisahan yang sehat biasanya mengikuti kapabilitas bisnis, misalnya ordering, payment, inventory, atau identity.

Pada monolit modular, Anda tetap harus punya batas domain yang disiplin. Bedanya, penegakan batas dilakukan lewat struktur kode, test, dan aturan dependensi, bukan lewat jaringan. Ini sering lebih murah untuk tahap awal.

3. Deployment: satu unit vs deploy independen

Monolit modular biasanya dideploy sebagai satu artefak. Ini memudahkan rollback dan menyederhanakan pipeline. Namun, perubahan kecil di satu modul bisa memicu retest dan redeploy seluruh aplikasi.

Microservice memungkinkan deploy per-domain. Ini berguna bila tim berbeda perlu bergerak tanpa saling menunggu atau jika sebagian domain punya kebutuhan scaling berbeda. Tetapi keuntungan ini baru terasa jika Anda sudah punya CI/CD yang matang, test kontrak, strategi versioning, dan lingkungan observability yang memadai.

4. Observability: jangan remehkan biaya melihat sistem

Pada monolit, log aplikasi dan stack trace sering cukup untuk melacak satu request. Pada microservice, satu request pengguna bisa melewati API gateway, service auth, service order, service payment, queue, worker, dan callback eksternal. Tanpa correlation ID, centralized logging, metrics, dan tracing, debugging akan lambat dan mahal.

Karena itu, microservice bukan hanya keputusan desain kode, tetapi juga keputusan investasi tooling operasional.

5. Kegagalan parsial adalah masalah nyata

Dalam monolit, pemanggilan antar-modul biasanya in-process: cepat dan relatif deterministik. Pada microservice, setiap panggilan jaringan bisa timeout, gagal sebagian, atau berhasil tetapi respons hilang. Anda harus mendesain untuk retry, circuit breaker, dead-letter queue, idempotency key, dan kompensasi.

Jika tim belum terbiasa menangani kegagalan parsial, microservice bisa menciptakan bug yang jauh lebih sulit daripada bug pada monolit.

6. Data ownership dan konsistensi

Ini titik paling sering disalahpahami. Pada microservice yang sehat, setiap service seharusnya memiliki database atau set data yang menjadi otoritasnya. Service lain tidak membaca tabel internalnya secara langsung. Pertukaran data dilakukan lewat API atau event.

Konsekuensinya, Anda sering harus menerima eventual consistency. Misalnya, status pembayaran sudah sukses di service billing, tetapi tampilan order di service ordering baru terbarui beberapa detik kemudian setelah event diproses.

Pada monolit modular, konsistensi transaksional lebih mudah dijaga karena semua berada dalam satu boundary proses dan sering dalam satu database. Ini sangat menguntungkan untuk fitur yang berubah cepat dan masih banyak direvisi.

7. Integrasi internal dan eksternal

Produk web modern sering bergantung pada payment gateway, email provider, analytics, CRM, search, atau identity provider. Jika integrasi eksternal adalah sumber utama kompleksitas, memecah internal system menjadi banyak microservice belum tentu membantu. Kadang yang lebih penting adalah membuat modul integrasi yang rapi, mekanisme retry yang baik, dan boundary anti-corruption agar provider eksternal tidak bocor ke seluruh kode aplikasi.

Kapan monolit modular lebih unggul

Untuk banyak produk web yang masih mencari bentuk fitur, monolit modular sering menjadi pilihan paling rasional jika kondisi berikut terpenuhi:

• Tim masih kecil atau menengah, dan orang yang sama sering menyentuh banyak domain.
• Batas domain belum stabil, sehingga pemisahan service terlalu dini justru memperbanyak migrasi API dan skema data.
• Perubahan fitur sangat sering, sehingga refactor dalam satu codebase lebih murah dibanding koordinasi antar-service.
• Kebutuhan observability dan platform ops masih terbatas.
• Transaksi lintas domain masih sering butuh konsistensi kuat.
• Deploy masih bisa ditangani sebagai satu unit tanpa bottleneck organisasi besar.

Keuntungan terbesar monolit modular bukan hanya sederhana, tetapi memungkinkan desain domain yang baik tanpa memaksa biaya distribusi terlalu cepat. Jika boundary modul dijaga sejak awal, monolit modular juga mempermudah ekstraksi service di masa depan karena domain sudah terpetakan.

Kapan microservice mulai masuk akal

Microservice layak dipertimbangkan bila beberapa sinyal berikut mulai muncul secara konsisten, bukan hanya sesekali:

• Tim bertumbuh dan domain ownership makin jelas, misalnya tim payment, tim catalog, dan tim fulfillment bekerja relatif mandiri.
• Deploy monolit mulai saling mengganggu, misalnya perubahan kecil di satu area menunda rilis area lain.
• Skala operasional per-domain berbeda jauh, misalnya modul pencarian atau notifikasi butuh pola scaling yang sangat berbeda.
• Batas domain sudah stabil dan dependency antar-domain dapat dibuat lebih longgar.
• Kebutuhan kepatuhan, keamanan, atau isolasi kegagalan memaksa sebagian domain dipisah.
• Tim sudah siap mengelola platform: observability, secret management, CI/CD, service discovery, API governance, dan incident response.

Microservice bukan keputusan arsitektur murni. Ia biasanya baru efektif ketika struktur tim dan struktur domain mendukungnya.

Matriks keputusan: pilih yang mana?

Jika Anda ragu, itu sendiri sering sinyal untuk memulai dari monolit modular dengan boundary yang ketat.

Pola implementasi monolit modular yang sehat

Monolit modular hanya unggul jika benar-benar modular. Beberapa aturan praktis:

• Pisahkan folder, namespace, dan API internal per-modul.
• Larangan akses database lintas modul secara langsung.
• Komunikasi antar-modul melalui interface, application service, atau event internal.
• Tulis test di level modul, bukan hanya test end-to-end global.
• Jangan membuat folder berdasarkan layer generik saja seperti controllers, services, helpers untuk seluruh aplikasi tanpa boundary domain.

Struktur sederhana:

src/
  modules/
    identity/
      api/
      application/
      domain/
      infrastructure/
    catalog/
      api/
      application/
      domain/
      infrastructure/
    ordering/
      api/
      application/
      domain/
      infrastructure/
  shared/
    logging/
    auth/
    messaging/

Contoh komunikasi antar-modul melalui event internal, bukan query langsung ke tabel modul lain:

// ordering/application/place_order.js
async function placeOrder(command, deps) {
  const order = await deps.orderRepo.create(command)
  await deps.eventBus.publish({
    type: 'OrderPlaced',
    orderId: order.id,
    customerId: order.customerId,
    total: order.total
  })
  return order
}

// notification/application/on_order_placed.js
async function onOrderPlaced(event, deps) {
  await deps.notificationService.sendOrderConfirmation({
    orderId: event.orderId,
    customerId: event.customerId
  })
}

Pola ini berguna karena saat nanti modul notification diekstrak menjadi service terpisah, kontrak interaksinya sudah lebih siap.

Jika memilih microservice, mulai dari area yang tepat

Jangan memecah seluruh sistem sekaligus. Ekstraksi service biasanya lebih aman jika dimulai dari domain yang memiliki salah satu karakteristik berikut:

• Boundary bisnisnya jelas dan relatif stabil.
• Beban scaling-nya unik dibanding bagian lain.
• Punya lifecycle deploy yang sering berbenturan dengan modul lain.
• Bisa menerima eventual consistency.
• Memiliki risiko kegagalan yang perlu diisolasi.

Contoh kandidat yang sering masuk akal lebih awal: notifikasi, pencarian, media processing, webhook processing, atau integrasi tertentu. Sebaliknya, domain inti yang masih terus berubah dan penuh transaksi lintas data sering lebih aman tetap di monolit modular sampai model domainnya matang.

Contoh kontrak event yang lebih aman

{
  "event_type": "billing.payment_captured",
  "event_id": "evt_12345",
  "occurred_at": "2026-08-31T10:15:00Z",
  "payload": {
    "payment_id": "pay_987",
    "order_id": "ord_456",
    "amount": 150000,
    "currency": "IDR"
  }
}

Yang penting bukan format JSON-nya, tetapi disiplin di sekitarnya: event punya identitas unik, konsumen idempoten, dan perubahan kontrak dilakukan hati-hati agar tidak merusak service lain.

Sinyal bahwa migrasi dari monolit modular ke microservice memang diperlukan

1. Lead time rilis memburuk karena saling tunggu antar-domain, bukan semata karena proses review yang jelek.
2. Refactor satu domain terus menimbulkan regresi di domain lain meski boundary modul sudah dicoba diperketat.
3. Skala dan pola trafik berbeda tajam sehingga scaling satu aplikasi menjadi boros.
4. Kebutuhan reliability per-domain berbeda, misalnya gangguan modul notifikasi seharusnya tidak memengaruhi checkout.
5. Kebutuhan kepatuhan atau keamanan memaksa pemisahan akses dan data.
6. Tim sudah punya kapasitas operasional untuk menjalankan banyak service dengan sehat.

Jika sinyal yang muncul hanya “codebase terasa besar”, itu belum cukup. Codebase besar sering lebih tepat diobati dengan modularisasi, arsitektur test yang lebih baik, dan penghapusan dependency silang.

Anti-pattern yang sering terjadi

1. Distributed monolith

Service dipisah secara fisik, tetapi saling bergantung kuat dan harus di-deploy bersama. Ini menggabungkan kerugian monolit dan microservice sekaligus.

2. Shared database antar-service

Ini merusak data ownership. Ketika banyak service membaca-menulis tabel yang sama, kontrak domain menjadi kabur dan perubahan skema jadi berbahaya.

3. Pecah berdasarkan layer teknis

Misalnya auth-service, user-service, email-service, file-service, tetapi satu use case bisnis nyata tetap harus memanggil semuanya secara berantai. Hasilnya coupling tinggi dengan boundary domain rendah.

4. Ekstraksi terlalu dini karena tren

Tim kecil sering menghabiskan lebih banyak waktu mengurus container, gateway, tracing, dan queue daripada membangun fitur inti.

5. Monolit modular palsu

Secara folder tampak rapi, tetapi semua modul bebas mengakses repository, model, dan tabel modul lain. Ini hanya kosmetik.

Dampak ke maintainability dan biaya tim

Untuk tim kecil

Tim kecil biasanya diuntungkan oleh monolit modular karena konteks pengembangan masih tersebar di sedikit orang. Mereka butuh feedback loop cepat, local setup sederhana, dan biaya operasional rendah. Maintainability yang baik datang dari boundary kode, test otomatis, dan disiplin dependensi, bukan dari jumlah service.

Untuk tim yang bertumbuh

Saat tim bertambah, maintainability mulai dipengaruhi oleh ownership. Jika setiap tim sering bentrok di codebase yang sama, perlu dievaluasi apakah masalahnya ada di proses, boundary modul, atau memang perlu pemisahan service. Microservice bisa membantu, tetapi hanya jika ownership domain dan kontrak antarsistem cukup matang.

Biaya yang sering terlupakan saat masuk ke microservice:

• pipeline build dan deploy per-service,
• monitoring dan alerting lebih banyak,
• manajemen rahasia dan akses service-to-service,
• versioning API dan test kontrak,
• debugging incident lintas service,
• duplikasi utilitas bersama jika boundary tidak jelas.

Checklist evaluasi arsitektur

Gunakan checklist ini sebelum memutuskan:

• Apakah domain inti produk sudah cukup stabil untuk dipisah?
• Apakah dua area yang ingin dipisah benar-benar bisa berubah dan deploy independen?
• Apakah eventual consistency dapat diterima oleh use case bisnis terkait?
• Apakah setiap service nantinya bisa memiliki data ownership yang jelas?
• Apakah tim siap membangun logging terpusat, metrics, tracing, dan alerting?
• Apakah kegagalan jaringan, retry, timeout, dan idempotency sudah dipahami?
• Apakah bottleneck saat ini berasal dari arsitektur, atau dari test lambat, review lambat, dan proses rilis yang buruk?
• Apakah struktur modul pada monolit sudah cukup disiplin, atau baru sekadar dipisah folder?
• Apakah ada domain yang memang butuh scaling atau compliance berbeda?
• Jika satu service gagal, apa dampak bisnisnya dan bagaimana fallback-nya?

Debugging dan tips praktis di lapangan

• Di monolit modular: buat aturan dependensi eksplisit, audit query lintas modul, dan tandai modul yang sering menjadi pusat dependency.
• Di microservice: selalu gunakan correlation ID dari entry point request sampai worker/event consumer.
• Mulai dari observability minimum: structured logging, dashboard error rate, latency, dan antrean backlog.
• Jika memakai event, pastikan consumer idempoten sejak awal. Event duplikat bukan anomali langka, melainkan kondisi yang harus diasumsikan.
• Jangan ekstrak service hanya karena satu modul “terasa besar”. Ukur: frekuensi perubahan, dependency silang, kebutuhan scaling, dan dampak deploy.

Kesimpulan

Dalam konteks web yang terus berubah, pertanyaan monolit modular vs microservice seharusnya dijawab dengan melihat batas domain, coupling nyata, pola deploy, observability, kegagalan parsial, data ownership, dan kapasitas tim, bukan dengan mengikuti pola populer.

Untuk banyak produk web, monolit modular adalah default yang kuat: lebih murah dioperasikan, lebih mudah di-debug, dan lebih cocok untuk domain yang masih bergerak. Microservice layak dipilih ketika domain sudah jelas, tim ownership sudah matang, dan biaya distribusi memang terbayar oleh kebutuhan deploy independen, scaling, atau isolasi kegagalan.

Jika ingin keputusan yang tahan lama, bangun monolit Anda seolah suatu hari sebagian modul akan dipisah. Dengan begitu, Anda tidak terkunci terlalu lama di monolit yang kusut, tetapi juga tidak membayar biaya microservice sebelum waktunya.