Kapan Modular Monolith Lebih Tepat daripada Microservices?

Modular monolith sering lebih tepat daripada microservices ketika produk masih bertumbuh, domain bisnis belum sepenuhnya stabil, dan tim ingin menjaga kecepatan delivery tanpa menanggung biaya operasional sistem terdistribusi. Jika kebutuhan utamanya adalah menjaga modularitas internal, konsistensi data, dan deployment yang lebih sederhana, modular monolith biasanya memberi hasil lebih baik di fase menengah daripada memecah service terlalu dini.

Pertanyaan yang tepat bukan sekadar “monolith vs microservices”, tetapi apakah batas domain, kebutuhan skala, dan struktur tim sudah cukup matang untuk arsitektur terdistribusi? Untuk banyak produk seperti e-commerce atau SaaS B2B yang sedang tumbuh, jawabannya sering masih “belum”. Di situ modular monolith menjadi pilihan yang pragmatis: tetap satu aplikasi untuk deployment, tetapi disiplin dalam pemisahan modul, kontrak internal, dan kepemilikan domain.

Mengapa modular monolith sering lebih unggul untuk tim produk yang sedang tumbuh

Microservices bukan sekadar memecah kode menjadi banyak repository atau banyak container. Begitu sistem dipisah, Anda juga memecah deployment pipeline, observability, komunikasi data, ownership, retry logic, failure mode, dan cara debugging. Semua itu adalah biaya tetap yang harus dibayar bahkan sebelum manfaat skalabilitasnya benar-benar terasa.

Modular monolith memberi kompromi yang berguna: batas domain tetap dipaksa di level kode dan dependensi, tetapi eksekusi masih berada dalam satu proses aplikasi dan biasanya satu database. Hasilnya, tim bisa melatih disiplin arsitektur tanpa langsung masuk ke kompleksitas jaringan dan operasi terdistribusi.

Kondisi yang biasanya cocok

• Produk masih sering berubah arah atau menemukan model bisnis yang tepat.
• Batas domain sudah mulai terlihat, tetapi belum cukup stabil untuk dijadikan service terpisah.
• Tim engineering mulai bertambah, namun belum ada kebutuhan kuat untuk otonomi deployment per domain.
• Sistem membutuhkan konsistensi transaksi lintas modul yang masih cukup sering.
• Masalah utama saat ini adalah maintainability kode, bukan bottleneck skala independen per domain.

Trade-off modular monolith vs microservices yang benar-benar terasa di lapangan

1. Biaya operasional

Dalam modular monolith, satu aplikasi biasanya berarti lebih sedikit moving parts: satu deployment unit utama, lebih sedikit konfigurasi jaringan, lebih sedikit service discovery, dan lebih sederhana dalam pengelolaan secret, logging, metrics, serta tracing. Ini penting untuk tim produk yang sedang tumbuh karena bottleneck mereka sering bukan kapasitas mesin, melainkan kapasitas operasional tim.

Pada microservices, biaya operasional meningkat karena setiap service membawa kebutuhan minimum yang hampir sama:

• pipeline build dan deploy sendiri,
• health check dan monitoring sendiri,
• konfigurasi environment sendiri,
• strategi rollback sendiri,
• logging, tracing, dan alerting sendiri.

Jika Anda punya 8 service kecil, Anda tidak sekadar punya 8 folder kode. Anda punya 8 unit operasi yang masing-masing bisa gagal dengan cara berbeda.

2. Kompleksitas deployment

Deployment modular monolith biasanya lebih mudah dikelola karena perubahan lintas modul bisa dirilis bersamaan. Untuk tim yang sering mengubah alur bisnis end-to-end—misalnya checkout, invoice, dan entitlement akses—ini mengurangi friksi koordinasi antar-service.

Pada microservices, perubahan satu fitur sering menyentuh beberapa service. Walau secara teori tiap service bisa deploy independen, dalam praktik banyak perubahan tetap butuh sinkronisasi kontrak API, event schema, kompatibilitas versi, dan rollout bertahap. Jika belum ada disiplin kuat pada backward compatibility, deployment justru menjadi lebih rapuh.

3. Observability dan debugging

Bug di modular monolith relatif lebih mudah ditelusuri: satu request biasanya mengalir di satu proses, satu stack trace, dan satu konteks transaksi. Anda masih perlu logging yang baik, tetapi belum harus menyusun korelasi antar-service secara konsisten.

Di microservices, observability yang layak bukan fitur tambahan; itu kebutuhan dasar. Tanpa trace ID, structured logging, metrics per service, dan pemahaman dependency graph, debugging akan sangat mahal. Banyak tim memecah layanan lebih cepat daripada kemampuan observability mereka berkembang, lalu kehilangan visibilitas ketika insiden terjadi.

Aturan praktis: jika tim belum konsisten dengan logging terstruktur, dashboard error, dan tracing request di satu aplikasi, memecah menjadi banyak service biasanya memperbesar kebingungan, bukan mengurangi.

4. Konsistensi data dan transaksi

Ini salah satu alasan terkuat mengapa modular monolith sering lebih tepat di fase pertumbuhan. Selama banyak use case masih membutuhkan transaksi lintas domain secara sinkron, satu aplikasi dengan satu boundary runtime akan jauh lebih sederhana.

Contoh e-commerce:

• membuat order,
• mengurangi stok,
• menerapkan promo,
• membuat invoice,
• mencatat audit log.

Dalam modular monolith, Anda bisa mengatur ini dengan transaksi database yang jelas dan aturan dependensi antar-modul yang ketat. Dalam microservices, transaksi ini berubah menjadi orkestrasi atau choreography berbasis event, idempotency, kompensasi, dan penanganan eventual consistency.

Itu bukan berarti microservices salah. Namun jika kebutuhan bisnis Anda belum toleran terhadap delay sinkronisasi, duplikasi event, atau kondisi parsial sementara, modular monolith biasanya lebih aman dan lebih murah.

5. Testing

Testing di modular monolith cenderung lebih mudah karena:

• integration test dapat menjalankan alur lintas modul dalam satu proses,
• test setup lebih sederhana,
• lebih sedikit kebutuhan mock jaringan,
• lebih sedikit potensi test flakiness akibat timeout atau ketergantungan antar-service.

Pada microservices, Anda perlu memikirkan kombinasi contract test, consumer-driven contract bila dipakai, integration test antar-service, test event flow, dan verifikasi kompatibilitas schema. Ini menambah kualitas bila dikerjakan benar, tetapi juga menambah beban engineering yang signifikan.

6. Koordinasi tim

Microservices sering masuk akal jika tim benar-benar perlu otonomi tinggi per domain: backlog berbeda, cadence rilis berbeda, dan kebutuhan skala operasional berbeda. Tetapi bila struktur tim masih sering berubah atau ownership belum tegas, microservices justru memindahkan coupling dari kode ke proses koordinasi manusia.

Dengan modular monolith, tim masih bisa membagi ownership per modul tanpa memaksa pemisahan operasional terlalu awal. Ini cocok untuk organisasi yang sedang tumbuh dari satu tim backend menjadi beberapa squad, tetapi belum siap dengan platform engineering yang matang.

7. Maintainability jangka menengah

Banyak orang menganggap monolith pasti sulit dirawat. Yang sebenarnya sulit dirawat adalah monolith yang tidak modular. Jika modular monolith dibangun dengan boundary yang jelas, aturan dependensi yang ketat, dan kontrak internal yang stabil, maintainability jangka menengah bisa sangat baik.

Keuntungan pentingnya adalah Anda bisa menunda keputusan distribusi fisik sampai benar-benar diperlukan. Ini menurunkan risiko salah memetakan domain terlalu dini, yang sering berujung pada service boundaries yang keliru dan mahal untuk diperbaiki.

Contoh konkret: e-commerce dan SaaS B2B

Contoh e-commerce

Bayangkan sistem memiliki modul:

• Catalog
• Inventory
• Cart
• Checkout
• Payment
• Order
• Promotion

Di fase pertumbuhan, perubahan bisnis biasanya lintas banyak modul sekaligus. Misalnya, aturan promo baru memengaruhi cart, checkout, order, dan invoice. Bila semuanya dipisah menjadi service terlalu cepat, setiap perubahan fitur akan menuntut sinkronisasi API atau event di banyak tempat.

Dengan modular monolith, Anda masih bisa menjaga batas domain seperti ini:

src/
  modules/
    catalog/
      application/
      domain/
      infrastructure/
      api/
    inventory/
    checkout/
    order/
    payment/
  shared/
    kernel/
    events/

Kuncinya bukan struktur folder semata, tetapi aturan bahwa modul checkout tidak boleh langsung mengakses tabel internal modul inventory secara bebas. Akses harus lewat interface, application service, atau event internal yang terdefinisi.

Contoh SaaS B2B

Pada SaaS B2B, modul umum bisa berupa:

• Tenant & IAM
• Subscription & Billing
• Workspace Management
• Reporting
• Notification
• Audit Log

Selama aturan billing, entitlement, dan provisioning masih sering berubah, modular monolith memudahkan perubahan lintas modul yang tetap konsisten. Service terpisah baru lebih masuk akal jika misalnya reporting punya kebutuhan komputasi berat, lifecycle deployment berbeda, atau beban query analitik yang sangat berbeda dari transaksi utama.

Ciri modular monolith yang sehat

Modular monolith bukan berarti “monolith biasa tetapi diberi nama baru”. Ia perlu batas internal yang nyata. Beberapa indikatornya:

• Setiap modul punya tanggung jawab domain yang jelas.
• Dependensi antar-modul satu arah dan dibatasi.
• Tidak ada akses sembarangan ke tabel atau class internal modul lain.
• Kontrak antar-modul eksplisit, misalnya interface atau domain event internal.
• Test bisa dijalankan per modul dan lintas modul secara terkendali.
• Perubahan di satu modul tidak memaksa rebuild mental seluruh sistem.

Jika semua modul tetap saling memanggil database yang sama tanpa aturan, maka Anda belum punya modular monolith; Anda hanya punya monolith besar dengan folder terpisah.

Contoh kontrak internal yang lebih aman

// Checkout hanya bergantung pada kontrak, bukan detail implementasi Inventory.
public interface InventoryReservationService {
    ReservationResult reserve(String productId, int quantity);
}

public final class CheckoutApplicationService {
    private final InventoryReservationService inventory;
    private final OrderRepository orders;

    public CheckoutApplicationService(
        InventoryReservationService inventory,
        OrderRepository orders
    ) {
        this.inventory = inventory;
        this.orders = orders;
    }

    public OrderId placeOrder(CheckoutCommand cmd) {
        var reservation = inventory.reserve(cmd.productId(), cmd.quantity());
        if (!reservation.success()) {
            throw new IllegalStateException("Stok tidak cukup");
        }

        var order = Order.createFrom(cmd);
        orders.save(order);
        return order.id();
    }
}

Contoh ini menunjukkan ide penting: modul checkout tahu apa yang dibutuhkan dari inventory, tetapi tidak tahu detail penyimpanan, query, atau struktur internal modul tersebut. Pola seperti ini membuat pemisahan ke service terpisah nanti jauh lebih mudah.

Tabel perbandingan untuk pengambilan keputusan

Sinyal bahwa sistem mulai perlu dipisah ke service terpisah

Modular monolith bukan tujuan akhir untuk semua sistem. Ada saat ketika memisah service memang masuk akal. Beberapa sinyal yang relatif kuat:

• Beban kerja sangat berbeda, misalnya modul reporting atau search membutuhkan skala dan resource profile yang jauh berbeda dari transaksi utama.
• Lifecycle deployment berbeda, misalnya modul tertentu sering dirilis tanpa ingin menyentuh aplikasi inti.
• Kebutuhan isolasi kegagalan jelas, contohnya proses asynchronous berat tidak boleh mengganggu request transaksional utama.
• Batas domain sudah stabil, dan kontrak antar-modul jarang berubah secara drastis.
• Kepemilikan tim sudah tegas, termasuk on-call, backlog, SLA internal, dan tanggung jawab operasional.
• Ketergantungan data lintas domain menurun, sehingga service bisa memiliki data sendiri tanpa banyak transaksi sinkron lintas batas.
• Observability dan platform sudah cukup matang, termasuk tracing, alerting, secret management, CI/CD, dan rollback.

Jika sinyal-sinyal ini belum ada, memecah ke microservices sering hanya mengubah masalah kode menjadi masalah koordinasi dan operasi.

Anti-pattern: memecah terlalu dini

1. Service per entitas

Memisah service menjadi User Service, Product Service, Order Service hanya karena nama entitas berbeda adalah anti-pattern umum. Domain boundary tidak sama dengan tabel database. Akibatnya, satu use case bisnis menjadi rangkaian panggilan jaringan yang rapuh.

2. Shared database antar-service

Ini sering dilakukan untuk “mempermudah transisi”, tetapi hasilnya buruk: service terlihat terpisah dari luar, namun sebenarnya tetap terikat pada skema data yang sama. Anda mendapat biaya microservices tanpa manfaat isolasi yang nyata.

3. Memecah karena alasan organisasi, bukan kebutuhan teknis dan domain

Jika service dibuat hanya agar tiap tim “punya service sendiri”, tetapi use case bisnis tetap saling terhubung erat, maka coupling akan pindah ke API call, event, dan rapat koordinasi.

4. Event-driven tanpa kebutuhan yang jelas

Event internal berguna, tetapi menjadikan semua interaksi asynchronous sejak awal sering membuat debugging dan konsistensi data lebih sulit. Gunakan event karena memang butuh loose coupling atau proses asynchronous, bukan karena terlihat modern.

5. Tidak menegakkan modularitas internal lebih dulu

Jika monolith Anda masih kacau, memecahnya menjadi banyak service biasanya hanya menghasilkan distributed monolith. Problem desain yang sama tetap ada, tetapi kini tersebar di jaringan.

Checklist keputusan untuk tech lead

Gunakan checklist ini sebelum memutuskan tetap di modular monolith atau mulai memisah service.

Pertahankan modular monolith jika sebagian besar jawaban berikut adalah “ya”

• Apakah banyak use case masih membutuhkan transaksi sinkron lintas domain?
• Apakah batas domain masih berubah cukup sering?
• Apakah tim belum punya observability dan platform deployment yang matang untuk sistem terdistribusi?
• Apakah bottleneck utama saat ini adalah maintainability internal, bukan kebutuhan skala independen?
• Apakah perubahan fitur sering menyentuh beberapa domain sekaligus?
• Apakah ownership tim per domain belum sepenuhnya stabil?
• Apakah satu deployment unit masih dapat diterima dari sisi risiko dan downtime?

Pertimbangkan memisah ke service jika sebagian besar jawaban berikut adalah “ya”

• Apakah ada modul dengan pola traffic dan resource yang sangat berbeda?
• Apakah ada kebutuhan isolasi kegagalan yang tidak bisa dicapai dengan cukup baik di satu aplikasi?
• Apakah kontrak antar-modul sudah stabil dan bisa dibuat eksplisit?
• Apakah modul tertentu benar-benar bisa memiliki data sendiri?
• Apakah tim memiliki kemampuan operasional untuk banyak deployment unit?
• Apakah observability, CI/CD, dan incident response sudah siap untuk arsitektur terdistribusi?
• Apakah manfaat otonomi deployment lebih besar daripada biaya koordinasi tambahan?

Langkah migrasi bertahap dari modular monolith ke service terpisah

Cara terbaik menuju microservices sering bukan memulai dengan microservices, melainkan mendesain monolith seolah suatu hari sebagian modul akan dipisah. Pendekatan bertahap ini menurunkan risiko arsitektur.

1. Tegakkan boundary internal. Pastikan modul berinteraksi lewat kontrak yang jelas, bukan akses langsung ke detail internal.
2. Kurangi query silang. Hindari modul membaca tabel modul lain secara bebas. Buat facade atau application service yang eksplisit.
3. Pisahkan alur sinkron dan asynchronous. Tandai proses mana yang memang butuh sinkron, mana yang cocok dipindah ke event atau job queue.
4. Tambahkan observability per modul. Walau masih satu aplikasi, ukur error rate, latency, dan throughput per domain.
5. Ekstrak modul paling mandiri lebih dulu. Biasanya candidate yang baik adalah search, notification, reporting, atau media processing—bukan core transaksi yang masih sangat terikat.
6. Jaga kompatibilitas kontrak. Saat modul dipisah, jadikan interface internal sebagai dasar API atau event contract eksternal.

Pendekatan ini lebih aman daripada “big bang rewrite” ke microservices, yang sering memakan waktu lama dan membekukan delivery fitur.

Kesalahan implementasi yang sering membuat modular monolith gagal

• Semua modul berbagi utilitas global berlebihan sampai batas domain jadi kabur.
• Service layer menjadi god object yang mengetahui terlalu banyak modul.
• Tidak ada aturan dependensi, sehingga modul saling mengimpor dua arah.
• Skema database tidak mencerminkan ownership, semua tabel dianggap boleh diakses siapa saja.
• Testing hanya end-to-end, sehingga regresi sulit dilokalisasi per modul.

Jika Anda ingin modular monolith berhasil, buat aturan arsitektur yang bisa diperiksa, misalnya melalui code review checklist, package conventions, atau pengujian arsitektur sederhana yang memverifikasi dependensi antar-modul.

Kesimpulan

Modular monolith lebih tepat daripada microservices ketika tim produk sedang tumbuh, domain belum sepenuhnya stabil, dan organisasi ingin menjaga modularitas tanpa membayar biaya distribusi terlalu dini. Keunggulannya paling terasa pada biaya operasional, deployment yang lebih sederhana, observability yang lebih mudah, konsistensi data, testing, koordinasi tim, dan maintainability jangka menengah.

Microservices menjadi masuk akal setelah batas domain matang, kebutuhan skala atau isolasi sudah jelas, dan kesiapan operasional memang ada. Sampai titik itu tercapai, pilihan paling dewasa sering bukan memecah sistem secepat mungkin, melainkan membangun modular monolith yang disiplin sehingga ekstraksi service nantinya menjadi keputusan teknis yang tenang, bukan reaksi terhadap kekacauan kode.