Composable / MACH Architecture

Bayangkan tim kamu sedang membangun platform e-commerce. Di tahun pertama, semuanya berjalan mulus. Kamu pakai satu monolit besar yang menangani katalog, keranjang, checkout, pembayaran, dan notifikasi. Satu tim, satu codebase, satu deployment. Cepat, sederhana, dan semua orang paham.

Setahun kemudian, tim berkembang. Sekarang ada tiga tim produk. Tim katalog ingin rilis fitur baru setiap hari, tapi terhambat karena harus menunggu tim checkout selesai mengerjakan perubahan besar di database. Tim mobile ingin menampilkan halaman produk yang lebih cepat, tapi backend monolit tidak bisa diubah tanpa mengganggu halaman web. Dan tim marketing ingin integrasi dengan search engine pihak ketiga, tapi integrasi itu harus nunggu rilis besar berikutnya.

Pada titik ini, monolit yang dulu jadi andalan mulai terasa seperti satu jalur sempit yang harus dilewati semua orang. Setiap perubahan kecil jadi urusan besar. Setiap rilis penuh drama. Dan yang paling menyakitkan: kamu tidak bisa mengganti satu komponen tanpa mengganti semuanya.

Masalah yang Diselesaikan

Masalah intinya bukan pada monolit itu sendiri. Masalahnya adalah ketika satu sistem harus melayani terlalu banyak kebutuhan yang bergerak dengan kecepatan berbeda. Tim katalog butuh kecepatan rilis tinggi, tim payment butuh stabilitas dan kepatuhan regulasi, tim mobile butuh API yang ringan, dan tim marketing butuh fleksibilitas integrasi.

Dalam arsitektur monolit, semua kebutuhan itu harus dinegosiasikan dalam satu jadwal rilis. Hasilnya: kompromi yang membuat semua pihak tidak puas, atau koordinasi yang menghabiskan energi tim.

Pola Composable atau MACH Architecture hadir untuk memecah kebuntuan ini. MACH sendiri adalah singkatan dari Microservices, API-first, Cloud-native SaaS, dan Headless. Intinya: setiap kemampuan bisnis dijalankan sebagai modul yang berdiri sendiri, bisa diganti, dan bisa dikembangkan secara independen.

Komponen Utama

Dalam arsitektur ini, ada lima blok yang saling terhubung.

Headless Frontend adalah lapisan presentasi yang terpisah dari backend. Bisa berupa Web App, Mobile App, Progressive Web App, atau bahkan dashboard IoT. Karena backend tidak mengikat tampilan, setiap kanal bisa punya pengalaman yang dioptimalkan tanpa mengganggu kanal lain.

API Gateway menjadi pintu masuk tunggal. Ia menangani routing, autentikasi, dan agregasi. Bisa berupa GraphQL Gateway, REST API Gateway, atau Auth Proxy. Fungsinya: menyembunyikan kompleksitas backend dari frontend, dan memastikan keamanan di satu titik.

Microservices adalah blok dominan. Setiap service mewakili satu kemampuan bisnis: Catalog Service, Cart Service, Checkout Service, Payment Service, Notification Service. Masing-masing punya domain logic sendiri, bisa di-deploy sendiri, dan bisa diskalakan sendiri.

Cloud-native SaaS adalah layanan pihak ketiga yang diintegrasikan via API. Contohnya Commerce Engine, CMS, Search, dan Personalization. Prinsipnya: jangan bangun ulang yang sudah jadi komoditas. Ambil yang terbaik dari ekosistem, lalu integrasikan.

Data & Persistence mengikuti pola database per service. Setiap microservice punya database sendiri, event store, cache, dan object storage. Ini disebut polyglot persistence: setiap service bebas memilih teknologi penyimpanan yang paling cocok untuk kebutuhannya.

Alur Kerja

Alur komunikasi dalam arsitektur ini cukup jelas. Headless Frontend mengirim request ke API Gateway. Gateway kemudian meneruskan ke Microservices atau SaaS yang relevan. Misalnya, ketika user mencari produk, request masuk ke Gateway, diteruskan ke Catalog Service, yang mengambil data dari databasenya sendiri.

Komunikasi antar microservices tidak dilakukan langsung via request-response terus-menerus. Mereka menggunakan Event Bus. Ketika Checkout Service menyelesaikan pesanan, ia mengirim event ke bus. Notification Service mendengar event itu dan mengirim email konfirmasi. Cart Service mendengar dan membersihkan keranjang. Pola ini membuat setiap service tetap independen dan tidak saling memblokir.

Data disimpan di database masing-masing service. Catalog Service punya database produk, Cart Service punya database keranjang, Payment Service punya database transaksi. Tidak ada database raksasa yang jadi bottleneck.

Kapan Pola Ini Cocok Dipakai

Arsitektur ini cocok ketika kamu punya beberapa tim produk yang perlu bergerak dengan kecepatan berbeda. Cocok untuk e-commerce, media platform, SaaS products, dan pengalaman digital skala besar yang harus melayani banyak kanal.

Cocok juga ketika kamu ingin menghindari vendor lock-in. Karena setiap komponen bisa diganti secara independen, kamu bisa memilih SaaS terbaik untuk search, CMS terbaik untuk konten, dan commerce engine terbaik untuk transaksi, tanpa terikat satu vendor.

Dan cocok ketika skalabilitas jadi kebutuhan nyata. Setiap service bisa diskalakan secara independen. Catalog Service yang kebanjiran traffic bisa ditambah instance tanpa menyentuh Payment Service yang mungkin tidak perlu ikut naik.

Trade-off, Batasan, dan Risiko Operasional

Tapi arsitektur ini bukan tanpa harga. Ada tiga trade-off utama yang harus kamu sadari.

Pertama, kompleksitas orkestrasi. Dengan puluhan service, kamu butuh cara yang rapi untuk mengatur komunikasi, deployment, dan monitoring. Tanpa tool yang tepat, tim bisa tenggelam dalam koordinasi antar service.

Kedua, konsistensi data. Karena setiap service punya database sendiri, tidak ada transaksi yang melintasi service. Kamu harus menerima eventual consistency. Pesanan mungkin sudah tercatat di Checkout Service, tapi butuh beberapa detik sebelum Notification Service tahu. Untuk banyak kasus ini tidak masalah, tapi untuk skenario yang butuh konsistensi kuat, ini jadi batasan serius.

Ketiga, biaya operasional. Tim DevOps harus matang. Kamu butuh container orchestration, service mesh, dan observability stack. Tim kecil dengan kapasitas DevOps terbatas akan kewalahan.

Implikasi Praktis untuk Tim Engineering

Jika tim kamu memutuskan ke arah ini, ada beberapa keputusan praktis yang perlu diambil:

Setiap service harus punya pemilik domain yang jelas. Jangan ada service yatim yang tidak ada yang bertanggung jawab.
API Gateway harus jadi prioritas keamanan. Di sinilah autentikasi, rate limiting, dan policy management ditempatkan. Gunakan mTLS dan OAuth2 untuk komunikasi antar service.
Event Bus harus dipilih dengan hati-hati. Ia jadi tulang punggung komunikasi asynchronous. Pilih yang punya jaminan delivery dan bisa di-scale.
Observability bukan opsional. Dengan banyak service, kamu tidak bisa mengandalkan debugging manual. Metrics, logging, dan tracing terdistribusi harus ada sejak awal.
Jangan tergoda membangun semuanya dari nol. Manfaatkan SaaS untuk fungsi yang sudah jadi komoditas. Fokuskan energi tim pada logika bisnis yang membedakan produkmu.

Arsitektur Composable bukan jawaban untuk semua masalah. Untuk aplikasi sederhana, tim kecil, atau skenario yang butuh transaksional ketat, monolit masih pilihan yang lebih bijak. Tapi ketika tim dan produk sudah tumbuh, dan kebutuhan bergerak ke arah yang berbeda-beda, pola ini memberi fleksibilitas yang sulit ditandingi.