Laravel: Kapan Pecah Monolith ke Service dan Kapan Jangan

Jawaban singkatnya: jangan memecah monolith Laravel ke service terpisah hanya karena ukuran codebase mulai besar atau karena ingin terlihat “lebih modern”. Dalam banyak kasus, monolith modular atau modular monolith masih menjadi pilihan paling efisien sampai ada batasan teknis atau organisasi yang benar-benar terasa: deployment saling mengganggu, ownership tim mulai kabur, kebutuhan scaling sangat berbeda, atau satu domain butuh reliabilitas dan lifecycle yang tidak cocok digabung dengan aplikasi utama.

Artikel ini fokus pada pertanyaan praktis: kapan Laravel sebaiknya tetap monolith, kapan cukup dimodularisasi, dan kapan sebagian fungsi memang layak dipisah menjadi service. Fokusnya bukan promosi microservices, melainkan trade-off nyata yang akan Anda hadapi di produksi: kompleksitas deployment, observability, latensi jaringan, konsistensi data, biaya operasional, dan dampak ke maintainability.

Memahami tiga pilihan arsitektur

1. Monolith modular

Ini masih satu aplikasi Laravel, satu proses deployment utama, biasanya satu database utama, tetapi struktur kode dipisah per domain atau bounded context seperti Auth, Catalog, Billing, dan Order. Pemisahan utamanya terjadi di level kode, namespace, route, service class, policy, event, dan test suite.

Pilihan ini cocok ketika tim masih kecil sampai menengah, domain masih sering berubah, dan kebutuhan utama adalah menjaga codebase tetap teratur tanpa menambah kompleksitas operasional.

2. Modular monolith

Istilah ini mirip dengan monolith modular, tetapi disiplin batas modulnya lebih ketat. Setiap modul idealnya punya kontrak internal yang jelas, tidak saling mengakses detail implementasi sembarangan, dan dependensi antar modul dijaga. Secara deployment tetap satu unit, tetapi secara desain mendekati pemisahan service.

Ini sering menjadi langkah paling masuk akal sebelum berpikir memecah service secara fisik. Kalau batas domain belum bisa ditegakkan di dalam satu repo dan satu aplikasi, biasanya memecah ke banyak service justru memperbesar kekacauan.

3. Service terpisah

Bagian tertentu dipisah menjadi aplikasi atau runtime sendiri, dengan deployment, observability, scaling, dan kadang database sendiri. Komunikasi bisa melalui HTTP API, queue, event bus, atau kombinasi beberapa mekanisme.

Pemisahan ini masuk akal bila ada alasan kuat, misalnya:

• kebutuhan scaling yang sangat berbeda,
• lifecycle deploy yang harus independen,
• isolasi kegagalan dibutuhkan,
• beban kerja sangat berbeda dari request web biasa,
• atau ada kebutuhan keamanan dan kepatuhan yang menuntut pemisahan yang lebih tegas.

Kenapa Laravel monolith sering masih tepat

Banyak sistem Laravel bertahan lama dengan arsitektur monolith yang sehat. Masalahnya sering bukan pada bentuk monolith itu sendiri, melainkan pada code organization, test yang lemah, boundary domain yang kabur, dan query/database yang tidak terkontrol.

Indikator monolith masih tepat

• Satu tim atau beberapa engineer masih bisa memahami alur sistem tanpa koordinasi lintas service yang berat.
• Perubahan fitur sering lintas domain, misalnya perubahan checkout menyentuh katalog, promo, stok, dan notifikasi sekaligus.
• Konsistensi data sinkron masih penting, contohnya order harus langsung valid terhadap stok dan status pembayaran tertentu.
• Operasional masih sederhana: satu pipeline CI/CD, satu stack logging, satu strategi rollback.
• Masalah utama ada di kode dan query, bukan di batas deployment atau ownership tim.
• Load belum menuntut scaling terpisah per domain.

Dalam kondisi ini, memecah service sering hanya memindahkan kompleksitas dari level kode ke level jaringan dan operasional. Anda mungkin merasa modul lebih “rapi”, tetapi sekarang harus menangani timeout, retry, circuit breaking, tracing, idempotency, dan sinkronisasi data.

Contoh yang masih cocok tetap monolith

Catalog + order + admin panel pada aplikasi e-commerce skala menengah sering masih lebih efektif dikelola dalam satu Laravel app. Query lintas domain, validasi bisnis, dan kebutuhan pengembangan fitur biasanya masih lebih mudah bila semuanya ada dalam satu boundary deployment.

Auth internal aplikasi bisnis juga sering belum perlu dipisah. Jika autentikasi hanya dipakai oleh satu produk utama, memisahkannya terlalu cepat justru menambah latensi login, kompleksitas token, dan dependency saat debugging.

Kapan monolith mulai menjadi bottleneck

Monolith bukan masalah sampai ia mulai menghambat perubahan, stabilitas, atau skala organisasi. Bottleneck ini bisa bersifat teknis maupun organisasi.

Bottleneck teknis

• Deploy satu fitur memaksa redeploy seluruh aplikasi, padahal ada domain tertentu yang berubah jauh lebih sering.
• Satu area dengan beban tinggi mengganggu area lain, misalnya proses billing atau import data berat membuat latency request utama ikut naik.
• Worker dan web request berbagi resource secara tidak sehat, sehingga antrean job, konsumsi memory, atau lock database mengganggu trafik pengguna.
• Kebutuhan availability berbeda, misalnya katalog boleh sedikit stale, tetapi billing harus sangat terkontrol dan audit-friendly.
• Batas keamanan berbeda, contohnya data pembayaran perlu pembatasan akses dan audit yang lebih ketat dibanding modul lain.

Bottleneck organisasi

• Ownership domain tidak jelas, banyak tim menyentuh modul yang sama tanpa kontrak yang tegas.
• Konflik merge dan koordinasi deployment tinggi.
• Kecepatan rilis melambat karena semua perubahan harus melewati jalur yang sama.
• Standar kualitas antar domain berbeda, tetapi dipaksa hidup dalam ritme yang sama.

Kalau bottleneck-nya organisasi, solusi pertama belum tentu service terpisah. Sering kali yang dibutuhkan adalah pemisahan ownership modul, aturan dependency, test kontrak internal, dan pipeline yang lebih disiplin.

Trade-off teknis yang harus dinilai sebelum memecah

1. Kompleksitas deployment

Monolith lebih sederhana: satu artifact, satu alur rollback, satu konfigurasi utama. Service terpisah memberi fleksibilitas deploy independen, tetapi setiap service menambah pipeline, environment, secret management, health check, dan koordinasi versi API.

Pertanyaan praktis: apakah domain itu benar-benar butuh lifecycle deploy terpisah, atau sebenarnya Anda hanya butuh pemisahan modul dan test yang lebih baik?

2. Observability

Di monolith, melacak request biasanya lebih mudah karena semuanya ada dalam satu boundary aplikasi. Begitu dipisah menjadi service, satu alur bisnis bisa melewati banyak hop: gateway, app utama, worker, service billing, provider eksternal, lalu callback.

Tanpa logging terstruktur, correlation ID, metrics, dan tracing, debugging akan jauh lebih sulit daripada saat masih monolith.

Kalau tim belum nyaman mengoperasikan logging terstruktur, dashboard metrics, dan tracing lintas proses, memecah service terlalu cepat biasanya berakhir pada “sulit dicari salahnya ada di mana”.

3. Latensi jaringan dan failure mode

Pemanggilan method internal di monolith nyaris tidak punya overhead jaringan. Pemanggilan antar service menambah latency, potensi timeout, retry storm, dan partial failure. Ini penting untuk domain yang sensitif terhadap pengalaman pengguna, seperti checkout dan login.

Service terpisah cocok bila domain tersebut tidak perlu selalu sinkron terhadap request pengguna, atau bisa ditangani secara asinkron dengan queue dan retry yang aman.

4. Konsistensi data

Ini salah satu trade-off terpenting. Dalam monolith, transaksi database lintas tabel masih relatif sederhana. Begitu dipisah, Anda tidak bisa mengandalkan transaksi database lintas service dengan cara yang sama. Anda akan masuk ke dunia eventual consistency, outbox pattern, idempotency key, kompensasi, dan penanganan duplikasi event.

Untuk domain seperti billing, ini bukan detail kecil. Kalau desain integrasi tidak matang, Anda bisa menghasilkan invoice ganda, status pembayaran tidak sinkron, atau order yang terlihat “berhasil” di satu service tetapi gagal di service lain.

5. Kebutuhan tim dan ownership

Service terpisah masuk akal bila ada tim yang benar-benar bisa memiliki domain tersebut end-to-end: schema, API, operasional, alerting, dan on-call. Kalau belum ada ownership yang jelas, service baru hanya menjadi monolith yang tersebar.

6. Biaya operasional

Setiap service tambahan berarti lebih banyak container/proses, queue, monitoring, log ingestion, secret, network rule, dan dokumentasi operasional. Secara teori arsitektur terlihat lebih “bersih”, tetapi biaya operasional bisa naik jauh.

7. Maintainability

Maintainability bukan sekadar ukuran repo. Monolith yang terstruktur sering lebih mudah dirawat daripada sekumpulan service kecil yang saling bergantung tanpa kontrak yang stabil. Pecah service hanya meningkatkan maintainability bila boundary domain jelas dan dependensi antar service minim.

Pola keputusan: monolith modular, modular monolith, atau service terpisah?

Pilih monolith modular jika

• produk masih sering berubah,
• domain belum stabil,
• tim belum besar,
• fitur sering butuh perubahan lintas modul,
• dan konsistensi sinkron lebih penting daripada isolasi deployment.

Praktiknya, fokuslah pada struktur domain di dalam Laravel: pisahkan namespace, action/service class, repository bila memang perlu, policy, event internal, queue, dan test per modul.

Pilih modular monolith jika

• monolith mulai besar tetapi belum ada alasan kuat untuk memecah deployment,
• Anda butuh batas domain yang lebih tegas,
• beberapa bagian sistem mulai punya owner berbeda,
• dan Anda ingin menyiapkan kemungkinan ekstraksi service di masa depan tanpa membayar kompleksitas jaringan sekarang.

Ini sering menjadi titik tengah terbaik. Anda mendapat disiplin arsitektur tanpa langsung membangun sistem terdistribusi.

Pilih service terpisah jika

• domain punya kebutuhan scaling, reliabilitas, atau security yang berbeda secara nyata,
• komunikasinya bisa dirancang lewat kontrak yang stabil,
• tim mampu mengoperasikan observability dan deployment terpisah,
• dan konsekuensi eventual consistency sudah dipahami serta diterima bisnis.

Contoh konteks nyata di Laravel

Auth

Jangan dipisah terlalu cepat bila auth hanya dipakai satu aplikasi utama. Menjadikan auth sebagai service sendiri berarti Anda harus mengelola token lifecycle, dependency jaringan saat login/refresh, otorisasi antar aplikasi, dan troubleshooting yang lebih rumit.

Layak dipisah bila auth menjadi platform bersama untuk banyak aplikasi yang benar-benar independen, punya kebutuhan keamanan yang lebih ketat, atau butuh lifecycle terpisah dari produk utama.

Billing

Sering menjadi kandidat kuat untuk dipisah, tetapi bukan dari hari pertama. Billing biasanya punya integrasi eksternal, audit trail, retry logic, webhook, rekonsiliasi, dan failure mode yang berbeda dari request web biasa.

Namun, sebelum dipisah, pastikan Anda siap menangani:

• idempotency untuk charge/invoice,
• status async dari payment provider,
• sinkronisasi status order dan pembayaran,
• serta monitoring alur yang tidak lagi sinkron.

Katalog

Biasanya masih cocok di monolith jika katalog terutama melayani aplikasi yang sama dan perubahan bisnisnya rapat dengan domain order. Tetapi katalog bisa dipisah bila read traffic sangat tinggi, indexing/search kompleks, atau ada kebutuhan cache dan skala baca yang sangat berbeda dari domain transaksi.

Worker / background processing

Ini sering salah dipahami. Banyak masalah “butuh microservice” sebenarnya cukup diselesaikan dengan memisahkan worker dari web app secara operasional, tanpa memecah codebase menjadi service mandiri.

Contohnya:

• web request tetap di Laravel app utama,
• job berat dipindahkan ke queue,
• worker dijalankan pada proses/host terpisah,
• dan antrean dibedakan berdasarkan prioritas.

Dengan pendekatan ini, Anda sudah mendapat isolasi resource tanpa harus membangun API antar service.

php artisan queue:work --queue=high,default
php artisan queue:work --queue=reports,imports --tries=3

Intinya bukan command-nya, tetapi polanya: pisahkan beban kerja dulu, baru putuskan apakah memang perlu memisahkan boundary aplikasi.

Implementasi praktis sebelum memecah service

Sebelum memutuskan ekstraksi service, rapikan monolith lebih dulu. Banyak tim melewatkan tahap ini, padahal justru ini yang memperjelas apakah pemisahan fisik memang diperlukan.

1. Buat boundary modul yang eksplisit

Kelompokkan kode per domain, bukan per tipe teknis semata. Misalnya, daripada semua controller, model, dan job bercampur, pisahkan domain Catalog, Billing, Auth, dan seterusnya.

app/
  Domain/
    Catalog/
      Actions/
      Models/
      Jobs/
      Policies/
    Billing/
      Actions/
      Services/
      Jobs/
      Events/
    Auth/
      Actions/
      Guards/

Struktur persisnya bisa berbeda, tetapi prinsipnya sama: dependency mengalir melalui kontrak yang jelas, bukan saling memanggil detail internal secara bebas.

2. Bedakan operasi sinkron dan asinkron

Kalau suatu proses tidak wajib selesai dalam request pengguna, dorong ke queue. Ini memberi sinyal apakah domain tersebut memang lebih cocok menjadi worker terisolasi atau bahkan service terpisah.

3. Terapkan event internal lebih dulu

Sebelum punya event antar service, biasakan event internal di monolith. Ini membantu mengurangi coupling langsung.

<?php

namespace App\Domain\Billing\Actions;

use App\Domain\Billing\Events\InvoicePaid;

class MarkInvoicePaid
{
    public function handle(string $invoiceId): void
    {
        // update status invoice
        // simpan audit trail

        event(new InvoicePaid($invoiceId));
    }
}

Kalau event internal ini ternyata sudah cukup untuk memisahkan alur kerja, Anda mungkin belum perlu service terpisah.

4. Siapkan kontrak data yang stabil

Jika satu domain mulai berpotensi dipisah, definisikan DTO, payload event, atau response contract dengan disiplin. Jangan biarkan modul lain bergantung pada model database atau object internal domain tersebut.

5. Ukur bottleneck dengan data

Jangan mengandalkan perasaan seperti “repo sudah besar” atau “controller sudah banyak”. Ukur hal yang benar-benar relevan:

• waktu build dan deploy,
• frekuensi konflik merge,
• error rate per domain,
• latency endpoint,
• durasi job queue,
• dan seberapa sering perubahan di satu domain memicu regresi di domain lain.

Anti-pattern: memecah terlalu cepat

1. Memecah berdasarkan layer teknis, bukan domain bisnis

Contoh buruk: membuat service terpisah untuk “user service”, “product service”, “order service” hanya karena tabelnya berbeda, padahal alur bisnisnya sangat saling terikat. Akibatnya, request sederhana berubah menjadi rantai network call yang rapuh.

2. Memecah karena repo terasa besar

Repo besar belum tentu masalah arsitektur. Bisa jadi masalah sebenarnya adalah boundary modul yang kabur, test lambat, atau coupling yang tinggi di dalam kode.

3. Memecah tanpa observability

Kalau belum ada tracing, log terstruktur, correlation ID, dan dashboard health yang memadai, debugging distributed system akan sangat mahal.

4. Memecah domain yang butuh transaksi kuat

Jika dua domain harus konsisten secara sinkron pada banyak alur inti, memecahnya terlalu cepat akan memaksa Anda menerima eventual consistency yang mungkin belum siap ditangani bisnis.

5. Mengganti panggilan internal menjadi HTTP tanpa alasan kuat

Ini anti-pattern klasik. Boundary fisik seharusnya lahir dari kebutuhan operasional dan domain, bukan sekadar mengganti method call dengan API call.

Debugging dan mitigasi jika sudah mulai memisah

• Gunakan correlation ID pada setiap request dan teruskan ke job, event, dan outbound call.
• Buat operasi penting idempotent, terutama pada billing, webhook, dan sinkronisasi status.
• Definisikan timeout dan retry dengan sadar; retry yang salah bisa memperparah beban dan menciptakan duplikasi.
• Pisahkan error bisnis dan error infrastruktur agar alerting tidak bising.
• Dokumentasikan kontrak API/event dan siapkan compatibility strategy saat payload berubah.

Checklist evaluasi sebelum memutuskan

1. Apakah masalah utama benar-benar berasal dari batas deployment, bukan kualitas struktur kode?
2. Apakah domain yang ingin dipisah punya ownership tim yang jelas?
3. Apakah domain tersebut punya kebutuhan scaling atau availability yang berbeda secara nyata?
4. Apakah bisnis siap menerima eventual consistency pada alur terkait?
5. Apakah observability lintas proses sudah cukup matang?
6. Apakah failure mode antar service sudah dipahami: timeout, retry, duplikasi, partial success?
7. Apakah service baru mengurangi coupling, atau hanya memindah coupling ke level API?
8. Apakah biaya operasional tambahan sebanding dengan manfaatnya?
9. Apakah queue/worker terpisah sudah dicoba sebagai solusi yang lebih murah?
10. Apakah kontrak data dan batas domain sudah stabil setidaknya pada area yang akan dipisah?

Matriks keputusan singkat

Penutup

Keputusan memecah monolith Laravel ke service bukan soal mengikuti tren arsitektur, melainkan soal memilih tempat kompleksitas yang paling murah untuk bisnis dan tim Anda. Selama boundary domain belum jelas, kebutuhan operasional belum berbeda secara nyata, dan konsistensi sinkron masih dominan, monolith modular atau modular monolith biasanya adalah pilihan terbaik.

Mulailah dari pemisahan domain di dalam aplikasi, isolasi worker, event internal, dan pengukuran bottleneck yang nyata. Jika setelah itu tetap ada domain yang membutuhkan deploy independen, skala berbeda, atau kontrol operasional khusus, barulah ekstraksi service menjadi langkah yang masuk akal dan lebih aman.