Composable Architecture untuk Tim Produk Indonesia: Cara Skala Lewat Modul, Bukan Rewrite

TL;DR: Composable Architecture adalah pendekatan menyusun sistem dari kapabilitas independen yang dirakit lewat API. Bagi tim produk Indonesia yang sudah punya monolit ramai pengguna, composable bisa diadopsi bertahap tanpa rewrite total, sehingga risiko bisnis tetap terkendali.

Beberapa tim produk yang saya temui di Jakarta dan Surabaya kerap berhadapan dengan dilema yang sama. Monolit warisan terasa lambat saat menambah kanal baru, sementara rewrite total terlalu mahal dan berisiko menghentikan pertumbuhan. Diskusi roadmap berakhir di tengah, dan inovasi tertunda.

Composable Architecture menawarkan jalan ketiga yang lebih realistis. Alih-alih membangun ulang dari nol, tim mengambil satu domain bisnis bernilai tinggi, mengisolasi kapabilitasnya, dan mengeksposnya sebagai modul yang dapat diganti tanpa menyentuh sisanya. Pendekatan ini sudah dibuktikan oleh banyak retailer global dan kini relevan untuk skala bisnis Indonesia.

Mengapa Monolit Warisan Sering Mengunci Pertumbuhan

Monolit yang dibangun cepat di fase awal biasanya menumpuk asumsi bisnis ke dalam kode yang sama. Saat tim ingin meluncurkan aplikasi mobile, integrasi marketplace baru, atau pengalaman headless commerce, seluruh basis kode harus dibuka dan diuji ulang. Konsekuensinya, kecepatan rilis menurun seiring usia produk.

Standar industri yang dirangkum oleh Martin Fowler tentang microservices menekankan bahwa kuncinya bukan pemecahan teknis semata, melainkan kejelasan batas domain bisnis sebelum pemisahan dilakukan.

Empat Pilar MACH yang Perlu Dipahami

Empat pilar ini bukan resep wajib sekaligus. Tim Indonesia yang baru mulai disarankan memilih dua pilar terlebih dahulu, biasanya API-first dan headless, sebelum melangkah ke microservices penuh.

Studi Kasus: Memodularkan Sistem Atmo dan Vetmo

Saat membangun Atmo (LMS) dan Vetmo (pet care), kami sengaja memisahkan modul autentikasi, pembayaran, dan katalog konten sejak awal. Pemisahan ini awalnya terasa berlebihan untuk skala kecil, namun terbayar saat fitur baru seperti subscription bulanan masuk roadmap. Modul pembayaran dapat diganti dari Midtrans ke Xendit dalam dua sprint tanpa menyentuh modul katalog. Hal yang sama berlaku saat menambah saluran notifikasi WhatsApp ke Vetmo, yang cukup menambah satu adapter di lapisan API tanpa rewrite halaman.

Pengalaman ini sejalan dengan pengamatan saya di proyek konsultasi yang lebih besar. Tim yang sebelumnya butuh 3-6 bulan untuk integrasi kanal baru biasanya turun ke kisaran 2-4 minggu setelah memisahkan setidaknya satu domain bisnis.

Pertanyaan Umum

Apakah Composable Architecture berarti harus pakai microservices sejak hari pertama?

Tidak. Banyak tim Indonesia berhasil dengan monolit modular yang menerapkan API-first dan headless dahulu, lalu memecah ke microservices saat tim sudah berukuran cukup untuk merawatnya.

Bagaimana mengukur keberhasilan adopsi composable?

Pantau waktu rata-rata dari ide kanal baru ke rilis publik, ukuran tim yang diperlukan untuk perubahan satu modul, dan jumlah insiden lintas modul. Ketiganya cenderung membaik dalam 1-2 kuartal jika adopsi berjalan benar.

Apakah composable cocok untuk UMKM dengan tim engineering kecil?

Belum tentu. Untuk tim di bawah 5 engineer, biaya operasional menjaga banyak modul biasanya lebih besar dibanding manfaat. Pendekatan modular monolith biasanya lebih hemat di tahap ini.

Bagaimana composable membantu strategi marketing?

Dengan modul pengalaman terpisah, tim marketing bisa meluncurkan landing campaign khusus tanpa antre rilis dengan tim produk. Hal ini mempercepat eksperimen kanal akuisisi.

Penutup

Composable Architecture bukan tentang teknologi paling baru, melainkan tentang membuat sistem yang sanggup berubah seiring strategi bisnis. Mulailah dari satu domain dengan nilai bisnis tertinggi, beri batas yang jelas, lalu rakit ulang ketika peluang baru datang.