Membangun aplikasi baru dengan microservices memang terdengar modern. Namun, memecah sistem menjadi puluhan layanan sejak hari pertama justru dapat membawa tim ke dalam kompleksitas yang sebenarnya belum dibutuhkan.
Di sinilah Strategi Memilih Modular Monolith menjadi menarik. Pendekatan ini mempertahankan kemudahan deployment sebuah monolith, tetapi struktur aplikasinya dibagi menjadi modul dengan tanggung jawab yang jelas.
Hasilnya, tim bisa bergerak cepat sekarang sekaligus menyiapkan fondasi apabila microservices benar-benar diperlukan di masa depan.
Kenapa Tidak Harus Langsung Menggunakan Microservices?
Microservices memberikan kemampuan seperti independent deployment, granular scaling, dan isolasi kegagalan. Masalahnya, semua keuntungan itu mempunyai biaya teknis dan operasional.
Setiap service membutuhkan mekanisme deployment, monitoring, komunikasi jaringan, logging, configuration management, hingga penanganan kegagalan.
Martin Fowler menyebut adanya microservice premium, yaitu tambahan biaya dan kompleksitas yang perlu dibayar ketika sebuah organisasi memilih arsitektur terdistribusi.
Untuk startup dengan lima developer dan satu produk yang baru mencari product-market fit, biaya tersebut mungkin belum sebanding dengan manfaatnya.
Tim justru bisa menghabiskan lebih banyak energi mengurus infrastrukur dibanding mengembangkan fitur yang dibutuhkan pengguna.
Apa Sebenarnya Modular Monolith?
Modular monolith tetap merupakan satu aplikasi yang biasanya dibangun dan di-deploy sebagai satu unit. Perbedaannya dengan monolith tradisional terletak pada struktur internalnya.
Aplikasi dibagi berdasarkan domain atau business capability. Sebagai contoh, aplikasi e-commerce dapat memiliki modul Catalog, Order, Payment, Inventory, dan Customer.
Thoughtworks menjelaskan bahwa modul dalam modular monolith memiliki batas fungsi yang jelas dan dapat dikembangkan serta diuji secara terpisah meskipun aplikasinya masih di-deploy bersama.
Struktur seperti ini juga membuat modul tertentu lebih mudah diekstraksi menjadi service jika diperlukan.
Modul Bukan Sekadar Folder
Kesalahan yang sering terjadi adalah menganggap modularisasi selesai hanya dengan membuat beberapa folder.
Modul yang sehat perlu memiliki API internal atau interface yang jelas. Modul Order, misalnya, tidak seharusnya langsung mengubah tabel milik Inventory tanpa melalui mekanisme yang telah ditentukan.
Tanpa aturan tersebut, modular monolith perlahan berubah menjadi monolith dengan dependesi kusut.
Kapan Strategi Memilih Modular Monolith Cocok?
Pendekatan ini sangat relevan ketika domain bisnis masih sering berubah.
Pada fase awal produk, tim mungkin belum mengetahui apakah pembayaran, promosi, subscription, atau fulfillment akan menjadi domain yang kompleks. Memisahkannya menjadi service terlalu awal berisiko menghasilkan batas service yang salah.
Modular monolith memungkinkan batas tersebut diperbaiki tanpa harus menghadapi komunikasi jaringan dan migrasi antarlayanan.
Pilihan ini juga masuk akal ketika ukuran tim masih kecil atau menengah, deployment aplikasi belum menjadi bottleneck, dan sebagian besar modul memiliki kebutuhan scaling yang relatif sama.
Microservices.io bahkan menekankan modularisasi sebagai salah satu cara meningkatkan maintainability dan team autonomy pada sistem monolithic.
Bangun Modul Berdasarkan Business Capability
Salah satu prinsip penting dalam Strategi Memilih Modular Monolith adalah menghindari pembagian sistem hanya berdasarkan lapisan teknis.
Daripada mempunyai modul besar bernama Controllers, Services, dan Repositories, pertimbangkan pembagian vertikal berdasarkan kebutuhan bisnis.
Misalnya:
Order mempunyai controller, business logic, repository, dan model sendiri. Hal yang sama berlaku untuk Payment dan Inventory.
Pendekatan ini membuat ownership menjadi lebih jelas. Developer yang mengerjakan proses pemesanan tidak harus memahami seluruh kompleksias aplikasi untuk melakukan perubahan kecil.
AWS juga merekomendasikan business capability dan subdomain sebagai dua pola penting ketika sistem monolithic nantinya perlu didekomposisi.
Jaga Data agar Batas Modul Tidak Bocor
Database sering menjadi titik paling sulit ketika modular monolith ingin berkembang menjadi microservices.
Pada tahap awal, menggunakan satu database masih sangat wajar. Namun, kepemilikan data sebaiknya tetap jelas.
Misalnya, tabel pembayaran menjadi milik modul Payment. Modul lain boleh meminta informasi pembayaran melalui interface yang disediakan, bukan membaca dan mengubah tabel tersebut sesuka hati.
Disiplin seperti ini mengurangi coupling.
Ketika Payment akhirnya membutuhkan deployment atau scaling independen, proses memindahkannya ke database dan service tersendiri menjadi lebih masuk akal dibanding membongkar query silang yang tersebar di seluruh codebase.
Gunakan Modular Monolith sebagai Alat Belajar Domain
Keuntungan besar modular monolith justru datang dari kemampuan untuk belajar.
Saat bisnis berkemabang, tim bisa melihat modul mana yang sering berubah, memiliki traffic terbesar, menyebabkan bottleneck, atau membutuhkan ritme deployment berbeda.
Informasi nyata tersebut jauh lebih bernilai dibanding menebak service boundary ketika produk bahkan belum mempunyai pengguna.
Inilah alasan gagasan monolith first cukup populer. Fowler mengamati bahwa banyak sistem microservices yang sukses berkembang dari sistem monolithic yang telah mencapai titik ketika pemisahan memang memberikan keuntungan nyata.
Tentukan Sinyal untuk Mulai Memecah Sistem
Modular monolith bukan berarti sistem harus menjadi monolith selamanya.
Perhatikan sinyal seperti satu modul membutuhkan scaling jauh lebih tinggi, deployment sebuah fitur kecil mengharuskan seluruh aplikasi dirilis, atau beberapa tim mulai saling menghambat karena bekerja pada codebase yang sama.
Kebutuhan teknologi berbeda juga bisa menjadi pemicu. Modul analitik, contohnya, mungkin membutuhkan runtime dan pola penyimpanan yang berbeda dari transaksi utama.
Saat sinyal tersebut muncul, ekstraksi dapat dilakukan secara bertahap. Fowler menyarankan migrasi monolith menuju microservices dilakukan melalui langkah evolusioner, dengan memisahkan capability yang benar-benar penting bagi bisnis.
Jangan Menganggap Microservices sebagai Tujuan Akhir
Arsitektur bukan perlombaan menuju jumlah service terbanyak.
Tujuannya adalah membangun sistem yang cukup sederhana untuk dikembangkan tetapi cukup fleksibel menghadapi pertumbuhan.
Jika satu aplikasi modular masih mampu melayani kebutuhan bisnis dengan baik, menambah network boundary hanya demi mengikuti tren tidak otomatis membuat sistem lebih baik.
AWS juga menekankan pentingnya menyeimbangkan manfaat segmentasi dengan kompleksitas yang dihasilkan karena kebutuhan setiap workload dapat berbeda.
Strategi Memilih Modular Monolith memberi tim jalan tengah antara monolith yang berantakan dan microservices yang terlalu dini.
Dengan batas domain yang jelas, kepemilikan data, serta interface antar-modul yang disiplin, aplikasi bisa tumbuh secara sehat.
Mulailah dari kebutuhan nyata, ukur bottleneck, lalu pindahkan modul menjadi microservice hanya ketika manfaatnya sudah jelas.