Gambar 1. Pelayanan pelanggan (sumber: pexels.com)

Selama satu dekade terakhir, industri perangkat lunak didominasi oleh satu tren arsitektur yaitu Microservices. Narasi yang dibangun adalah bahwa untuk mencapai skala besar (scale), kita harus memecah aplikasi menjadi ratusan layanan kecil yang terdistribusi. Monolith dianggap sebagai “barang antik” yang kaku dan sulit dikelola. Namun, memasuki tahun 2026, pendulum arsitektur telah berayun kembali. Fenomena yang dikenal sebagai “The Great Microservices Retraction” sedang terjadi. Tim engineering mulai menyadari bahwa kompleksitas terdistribusi, serialization overhead, dan mimpi buruk debugging, seringkali memakan biaya lebih besar daripada manfaat yang ditawarkan, terutama bagi tim yang bukan sekelas Google atau Netflix.

Yang ditinggalkan bukan ide “service-oriented” secara keseluruhan, melainkan microservices yang terlalu granular, diadopsi terlalu dini, untuk produk yang sebenarnya belum butuh distribusi kompleks. Beberapa indikasi tren:

  • Laporan dan artikel industri 2024–2026 menunjukkan semakin banyak organisasi yang melakukan rollback dari microservices ke monolith atau modular monolith, terutama untuk aplikasi skala kecil-menengah.
  • Perusahaan seperti Amazon (Prime Video), Shopify, dan beberapa unicorn lain secara terbuka membagikan cerita bagaimana mereka menggabungkan kembali sejumlah service ke satu deployment untuk menurunkan kompleksitas dan biaya operasional.

Solusi Jalan Tengah: The Modular Monolith

Modular Monolith bukanlah kembali ke “Spaghetti Code”. Ini adalah arsitektur di mana kode berada dalam satu deployable unit (satu repo, satu binary/container), namun secara internal terstruktur dengan sangat ketat berdasarkan domain bisnis (Bounded Contexts). Berikut beberapa prinsip modular monolith yang dapat diterapkan

  1. Domain-Centric, Bukan Layer-Centric

Alih-alih mengorganisir project seperti ini:

 

 

 

Modular monolith mengorganisir berdasarkan domain bisnis:

 

 

 

 

Di dalam tiap domain, baru dipecah lagi berdasarkan kebutuhan (application, domain, infra):

 

 

 

 

 

 

Setiap domain/module:

  • Memiliki reason to exist yang jelas.
  • Mengenkapsulasi business logic terkait domain itu.
  • Tidak “menyentuh” domain lain secara langsung, kecuali melalui interface/API yang disepakati.

  1. Batas Modul yang  Jelas dan Tegas

Supaya monolith tidak berubah menjadi “big ball of mud”:

  • Setiap modul memiliki public API yang boleh diakses modul lain.
  • Detail internal modul (entity, helper, dsb.) disembunyikan (misalnya dengan pengaturan package/namespace/visibility).
  • Aturan dependency dijaga:
    • Hindari circular dependency antar modul.
    • Usahakan dependency searah (misalnya: orders boleh tergantung payments, tapi payments tidak boleh bergantung balik ke orders).

Di banyak bahasa, ini bisa ditegakkan dengan:

  • Struktur folder/package yang disiplin.
  • Tool seperti ArchUnit (Java/Kotlin) atau rule khusus di linter untuk memvalidasi dependency.

 

  1. High Cohesion, Low Coupling

Modul yang sehat:

  • High cohesion: fungsi-fungsi yang sering berubah bersama berada di modul yang sama.
  • Low coupling: perubahan di satu modul tidak memaksa perubahan di modul lain.

Beberapa indikasi desain yang buruk:

  • Satu change feature kecil mengharuskan menyentuh 4–5 modul berbeda.
  • Modul saling bergantung (A -> B -> C -> A).

 

  1. Layering yang Sehat (Clean Architecture / Hexagonal)

Di dalam tiap modul, gunakan layering yang jelas:

  • Domain layer: entity, value objects, business rules.
  • Application layer: use case, orchestration, transaction boundary.
  • Infrastructure layer: DB access, REST client, message broker, dsb.
  • Interface/API layer: controllers, endpoint, handler.

Prinsipnya domain tidak tahu detail infrastruktur, sehingga logic inti tetap bersih dan mudah dites.

 

  1. Komunikasi Antar Modul

Karena semua modul masih berada dalam satu proses:

  • Untuk komunikasi sinkron: cukup method call ke public API modul lain.
  • Untuk event-driven: bisa gunakan event bus in-process, lalu jika suatu saat butuh di-distribute ke message broker, transisi lebih mudah.

 

 

Referensi:

  • https://byteiota.com/microservices-rollback-2026-42-return-to-monoliths/
  • https://byteiota.com/modular-monolith-42-ditch-microservices-in-2026/
  • https://www.kamilgrzybek.com/blog/posts/modular-monolith-domain-centric-design
  • https://www.geeksforgeeks.org/system-design/what-is-a-modular-monolith/
  • https://binaryigor.com/modular-monolith-dependencies-and-communication.html
  • https://www.thereformedprogrammer.net/my-experience-of-using-the-clean-code-architecture-with-a-modular-monolith/