Laravel: Kapan Monolith Bertingkat Lebih Tepat daripada Microservices

Laravel: Saat Monolith Bertingkat lebih tepat daripada microservices biasanya bukan soal tren arsitektur, tetapi soal biaya, kompleksitas, dan kebutuhan nyata sistem. Pada banyak aplikasi Laravel, terutama yang dibangun oleh tim kecil hingga menengah, modular monolith sering menjadi pilihan yang lebih rasional dibanding langsung memecah sistem menjadi banyak service terpisah.

Jawaban singkatnya: pakai monolith bertingkat atau modular monolith selama sebagian besar beban bisnis, tim, deployment, dan scaling masih bisa dikelola dalam satu aplikasi. Microservices mulai layak ketika ada batas domain yang benar-benar jelas, kebutuhan scaling yang berbeda antar komponen, atau kendala organisasi dan operasional yang tidak lagi bisa diatasi secara sehat di dalam satu codebase.

Apa yang dimaksud dengan monolith bertingkat di Laravel?

Monolith bertingkat adalah satu aplikasi yang dideploy sebagai satu unit, tetapi struktur internalnya dipisah dengan disiplin. Pada Laravel, ini biasanya berarti:

• Layer presentasi: controller, request validation, response transformer.
• Layer aplikasi: use case, service class, command handler.
• Layer domain: aturan bisnis inti, policy bisnis, entity/value object bila diperlukan.
• Layer infrastruktur: Eloquent repository, queue, mail, cache, integrasi eksternal.

Jika diperdalam menjadi modular monolith, setiap domain bisnis seperti Billing, Catalog, Order, User, atau Reporting memiliki folder, service, event, policy, dan test sendiri. Aplikasi tetap satu deployment, satu pipeline utama, dan sering kali satu database, tetapi batas antar domain dijaga secara sadar.

Ini penting karena banyak masalah yang orang coba selesaikan dengan microservices sebenarnya bisa diselesaikan lebih murah lewat struktur kode yang baik, batas modul yang tegas, queue yang sehat, cache, dan optimasi query.

Mengapa banyak aplikasi Laravel belum perlu microservices?

1. Deployment jauh lebih sederhana

Pada monolith, satu perubahan umumnya berarti satu build, satu artifact, dan satu deployment. Ini mengurangi kemungkinan mismatch kontrak API antar service, versi yang tidak sinkron, atau kegagalan rilis karena dependency jaringan internal.

Pada microservices, bahkan perubahan kecil pada alur bisnis dapat menyentuh beberapa service sekaligus. Tim perlu menangani:

• versioning API internal,
• koordinasi deployment lintas service,
• backward compatibility,
• strategi rollback yang lebih rumit.

Untuk tim Laravel yang belum punya platform engineering kuat, kompleksitas ini sering lebih mahal daripada manfaatnya.

2. Observability lebih mudah

Di monolith, satu request HTTP biasanya bisa ditelusuri dalam satu aplikasi: log, exception, query database, dan queue terkait ada dalam konteks yang sama. Di microservices, request yang sama bisa melewati API gateway, auth service, order service, payment service, queue worker, dan callback eksternal.

Tanpa tracing terdistribusi, correlation ID, standar logging, metrics, dan alerting yang matang, debugging justru menjadi lebih sulit. Banyak tim memecah service lebih cepat daripada kesiapan observability mereka.

Jika tim Anda masih sering bingung melacak satu request di dalam satu aplikasi Laravel, memecahnya menjadi lima service hampir pasti memperburuk debugging.

3. Konsistensi data lebih mudah dijaga

Monolith memungkinkan transaksi database yang lebih langsung untuk proses yang memang satu kesatuan, misalnya membuat order, mengurangi stok, mencatat invoice awal, dan menulis audit log. Pada microservices, operasi yang sama biasanya berubah menjadi eventual consistency, saga, outbox pattern, atau retry berbasis message queue.

Pendekatan tersebut valid, tetapi menambah kompleksitas desain dan pengujian. Jika bisnis Anda belum membutuhkan pemisahan itu, mempertahankan konsistensi dalam monolith biasanya lebih aman.

4. Biaya operasional lebih rendah

Microservices membawa biaya tambahan yang sering diremehkan:

• lebih banyak container atau proses runtime,
• lebih banyak CI/CD pipeline,
• lebih banyak konfigurasi environment dan secret,
• lebih banyak monitoring endpoint, worker, dan antrean,
• lebih banyak kebijakan keamanan antar service.

Pada Laravel, satu aplikasi monolith yang sehat sering cukup ditopang oleh web server, PHP runtime, database, Redis, queue worker, scheduler, dan object storage. Untuk banyak produk internal, admin panel, atau SaaS tahap awal, ini sudah memadai.

Tabel perbandingan: monolith bertingkat vs microservices

Kapan monolith bertingkat masih menjadi pilihan terbaik?

1. Admin panel dan backoffice internal

Admin panel biasanya punya domain yang luas tetapi trafik tidak ekstrem. Tantangan utamanya sering ada pada otorisasi, audit log, ekspor data, workflow approval, dan integrasi dengan sistem lain. Ini cocok untuk modular monolith karena:

• fitur saling terkait erat,
• laporan dan query lintas modul sering dibutuhkan,
• tim ingin perubahan cepat tanpa koordinasi lintas service.

Memecah admin panel menjadi banyak service terlalu dini sering membuat operasi sederhana menjadi panggilan jaringan berantai.

2. E-commerce skala kecil hingga menengah

Pada e-commerce, banyak orang langsung membayangkan Catalog, Cart, Checkout, Payment, Inventory, dan Notification sebagai service terpisah. Secara konsep bisa, tetapi untuk banyak bisnis, modular monolith lebih masuk akal pada fase awal hingga menengah.

Alasannya:

• alur checkout perlu konsistensi yang baik,
• perubahan bisnis sering lintas modul,
• laporan operasional butuh akses data gabungan,
• bottleneck performa sering berasal dari query, cache, atau integrasi eksternal, bukan dari bentuk arsitektur semata.

Selama lonjakan trafik masih bisa ditangani dengan cache, queue, read replica, atau pemisahan worker, monolith sering masih cukup.

3. SaaS B2B dengan workflow kompleks

SaaS B2B sering punya aturan bisnis yang rumit: role-based access, approval chain, billing, subscription, audit trail, dan tenant isolation. Sistem seperti ini biasanya lebih sulit pada level domain daripada pada level throughput. Modular monolith membantu karena:

• aturan bisnis dapat dipusatkan dan diuji lebih mudah,
• refactor lebih murah,
• fitur lintas domain tetap bisa dikembangkan cepat.

Jika tenant belum menuntut isolasi operasional ekstrem, memecah service terlalu awal justru memperbesar beban maintenance.

4. Sistem dengan queue berat tetapi domain masih satu

Adanya queue berat bukan berarti Anda harus pindah ke microservices. Banyak aplikasi Laravel bisa menangani beban asynchronous besar dengan tetap monolith, selama worker dipisah dengan baik dan job dirancang idempoten.

Contoh kasus:

• generate invoice massal,
• sinkronisasi katalog ke marketplace,
• pengiriman email dan webhook,
• proses import/export CSV besar,
• thumbnailing atau enrichment data.

Di sini yang Anda butuhkan sering kali adalah:

• queue terpisah per prioritas,
• worker khusus per jenis job,
• retry policy yang tepat,
• rate limiting untuk integrasi eksternal,
• monitoring backlog dan kegagalan job.

Semua itu bisa dilakukan tanpa memecah aplikasi menjadi service terpisah.

Tanda bahwa monolith Laravel masih cukup

• Tim engineering kecil hingga menengah dan belum punya peran khusus untuk platform, DevOps, atau SRE.
• Perubahan fitur sering lintas domain sehingga memecah service justru menambah koordinasi.
• Scaling masalahnya belum spesifik; bottleneck masih ada di query lambat, N+1 query, cache miss, atau job queue yang tidak sehat.
• Satu database masih cukup dikelola dan belum ada tekanan isolasi data yang kuat antar domain.
• Waktu debugging masih bisa diterima dengan log aplikasi, query log, dan dashboard queue yang ada.
• Deployment tunggal masih stabil dan durasi build/deploy belum menjadi masalah besar.
• Kebutuhan availability belum menuntut isolasi kegagalan ekstrem antar domain.

Jika sebagian besar poin ini benar, microservices kemungkinan belum memberi manfaat bersih yang positif.

Tanda bahwa pemisahan service mulai layak dipertimbangkan

• Batas domain sudah jelas dan relatif stabil, misalnya Billing dan Reporting benar-benar bisa hidup dengan kontrak data yang tegas.
• Kebutuhan scaling berbeda drastis; misalnya komponen ingestion atau webhook butuh scale tinggi, tetapi modul admin tidak.
• Siklus rilis antar domain berbeda; tim ingin deploy modul tertentu lebih sering tanpa menyentuh bagian lain.
• Kegagalan satu domain seharusnya tidak mengganggu domain lain, misalnya notifikasi gagal tidak boleh memblokir transaksi inti.
• Tim sudah mampu mengelola observability terdistribusi: tracing, metrics, log aggregation, alerting, dan correlation ID.
• Ketergantungan organisasi menuntut pemisahan; beberapa tim benar-benar bekerja semi-independen dengan ownership domain yang kuat.
• Regulasi atau isolasi keamanan menuntut batas teknis yang lebih tegas untuk data atau akses tertentu.

Perlu dicatat: satu atau dua tanda saja belum cukup. Microservices layak ketika manfaatnya konsisten di beberapa dimensi sekaligus: domain, tim, operasional, dan scaling.

Risiko over-engineering yang paling sering terjadi

1. Memecah service sebelum batas domain matang

Akibatnya, satu use case bisnis harus berpindah-pindah service. Hasilnya bukan kemandirian, tetapi coupling melalui jaringan. Coupling tetap ada, hanya bentuknya lebih sulit dideteksi dan diuji.

2. Mengira queue sama dengan microservices

Queue adalah mekanisme asynchronous. Ia bisa dipakai di monolith maupun microservices. Menambahkan Redis, worker, dan antrean prioritas tidak otomatis berarti arsitektur Anda harus dipecah menjadi service terpisah.

3. Mengabaikan biaya debugging distribusi

Masalah seperti timeout, retry ganda, duplicate message, race condition, dan data eventual consistency lebih jarang terlihat di lokal, tetapi sering muncul di produksi. Tanpa desain idempoten dan observability, tim mudah terjebak pada bug yang sulit direproduksi.

4. Membuat service yang terlalu kecil

Service yang terlalu granular menambah overhead komunikasi. Jika setiap operasi sederhana membutuhkan beberapa panggilan jaringan internal, latency, kompleksitas auth, dan risiko kegagalan akan meningkat.

Pola modular monolith yang praktis di Laravel

Anda tidak perlu menunggu sampai sistem besar untuk menata monolith. Struktur yang rapi sejak awal justru mempermudah keputusan migrasi nanti.

Contoh pengelompokan modul

app/
  Modules/
    Catalog/
      Actions/
      Models/
      Policies/
      Jobs/
      Events/
      Listeners/
    Orders/
      Actions/
      Models/
      Services/
      Jobs/
    Billing/
      Actions/
      DTO/
      Services/
      Integrations/
    Shared/
      Support/
      Concerns/
      Exceptions/

Nama folder bisa berbeda, tetapi prinsipnya sama: kelompokkan berdasarkan domain bisnis, bukan hanya tipe teknis global. Ini membantu developer melihat boundary lebih jelas.

Contoh alur service internal

<?php

namespace App\Modules\Orders\Actions;

use App\Modules\Orders\Models\Order;
use App\Modules\Billing\Services\InvoiceService;
use Illuminate\Support\Facades\DB;

class PlaceOrderAction
{
    public function __construct(private InvoiceService $invoiceService)
    {
    }

    public function execute(array $payload): Order
    {
        return DB::transaction(function () use ($payload) {
            $order = Order::create([
                'customer_id' => $payload['customer_id'],
                'status' => 'pending',
                'total' => $payload['total'],
            ]);

            foreach ($payload['items'] as $item) {
                $order->items()->create([
                    'product_id' => $item['product_id'],
                    'qty' => $item['qty'],
                    'price' => $item['price'],
                ]);
            }

            $this->invoiceService->createDraftForOrder($order);

            return $order;
        });
    }
}

Contoh ini menunjukkan bahwa di dalam monolith, lintas modul masih bisa berjalan dengan transaksi yang jelas. Jika nanti Billing benar-benar perlu dipisah, action seperti ini membantu Anda mengidentifikasi kontrak yang harus diekstrak.

Gunakan queue untuk isolasi beban, bukan langsung memecah service

<?php

namespace App\Modules\Catalog\Jobs;

use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Queue\SerializesModels;

class SyncProductToMarketplace implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;

    public $queue = 'marketplace-sync';

    public function __construct(public int $productId)
    {
    }

    public function handle(): void
    {
        // Ambil data terbaru dari DB, panggil API marketplace,
        // tangani retry dan logging secukupnya.
    }
}

Dengan antrean terpisah, Anda bisa scale worker tertentu tanpa harus memecah aplikasi. Misalnya worker untuk marketplace-sync diperbanyak, sementara web node tetap sama.

Batas scaling: kapan monolith mulai terasa sempit?

Monolith bukan berarti tidak bisa scale. Dalam banyak deployment Laravel, Anda masih bisa melakukan:

• horizontal scaling untuk web node,
• worker queue terpisah per antrean,
• cache untuk query atau response tertentu,
• read replica untuk beban baca,
• pemisahan scheduler/worker/web process,
• optimasi query dan indexing database.

Masalah muncul ketika kebutuhan scale benar-benar asimetris. Contohnya:

• ingestion webhook ratusan ribu event per jam sementara aplikasi utama relatif tenang,
• modul reporting menjalankan query berat yang tidak seharusnya berbagi resource dengan transaksi utama,
• pipeline dokumen atau media processing membutuhkan runtime dan dependency berbeda.

Pada titik ini, ekstraksi service atau setidaknya proses terpisah bisa masuk akal. Namun, pemisahan sebaiknya dimulai dari bagian yang paling jelas beban dan batas domainnya, bukan sekaligus memecah seluruh sistem.

Checklist evaluasi keputusan arsitektur

Gunakan checklist berikut sebelum memutuskan tetap monolith atau mulai memecah service:

1. Apakah bottleneck utama sudah terukur? Jika belum, ukur dulu query lambat, backlog queue, penggunaan CPU/memori, dan latency integrasi eksternal.
2. Apakah masalah bisa diselesaikan dengan modularisasi internal? Banyak codebase kacau bukan karena monolith, tetapi karena boundary tidak dijaga.
3. Apakah kebutuhan scaling benar-benar berbeda antar domain? Jika semua bagian scale bersama, microservices belum tentu membantu.
4. Apakah tim siap mengelola distributed systems? Termasuk tracing, timeout, retry, circuit breaker, dan idempotency.
5. Apakah kontrak antar domain sudah cukup stabil? Jika masih sering berubah, memecah service akan memperlambat iterasi.
6. Apakah ada kebutuhan isolasi keamanan atau compliance? Ini bisa menjadi alasan teknis yang valid untuk pemisahan.
7. Apakah pipeline deployment dan rollback sudah matang? Tanpa ini, banyak service berarti banyak titik gagal.
8. Apakah kegagalan parsial memang harus diisolasi secara teknis? Jika ya, identifikasi domain yang paling kritis untuk dipisah lebih dulu.

Rekomendasi bertahap migrasi yang aman untuk tim Laravel kecil hingga menengah

Tahap 1: Rapikan monolith lebih dulu

• Kelompokkan kode berdasarkan domain.
• Kurangi akses lintas modul yang sembarangan.
• Pusatkan aturan bisnis di action/service/use case, bukan di controller.
• Tambahkan test integrasi untuk alur penting.
• Perbaiki observability: log terstruktur, monitoring queue, dan error tracking.

Sering kali, setelah tahap ini, kebutuhan microservices ternyata belum mendesak.

Tahap 2: Pisahkan beban proses, bukan domain dulu

• Bedakan web process, scheduler, dan worker queue.
• Buat antrean per prioritas atau per tipe workload.
• Scale worker tertentu secara independen.

Ini memberi manfaat operasional nyata tanpa menambah kompleksitas boundary jaringan.

Tahap 3: Ekstrak integrasi yang memang cocok menjadi komponen terpisah

Kandidat yang umum:

• webhook ingestion dengan trafik sangat tinggi,
• document/media processing,
• sinkronisasi pihak ketiga yang punya retry dan rate limit kompleks.

Fokus pada komponen yang secara operasional berbeda dari aplikasi inti.

Tahap 4: Gunakan kontrak yang jelas sebelum memecah domain inti

Sebelum Billing atau Order diekstrak menjadi service, pastikan:

• API atau event kontraknya jelas,
• ownership data didefinisikan,
• idempotency untuk operasi penting sudah dipikirkan,
• fallback dan retry behavior sudah dirancang.

Jangan memulai dari domain paling sensitif jika tim belum terbiasa menangani failure mode terdistribusi.

Tahap 5: Migrasi satu service pada satu waktu

Hindari pemecahan besar-besaran. Pilih satu domain atau satu workload dengan justifikasi kuat, ukur hasilnya, lalu evaluasi apakah biaya operasional tambahan benar-benar sepadan.

Kesalahan umum saat transisi dari monolith ke service terpisah

• Shared database antar service terlalu lama sehingga boundary menjadi semu.
• Event tanpa ownership yang jelas, menyebabkan duplikasi tanggung jawab.
• Retry tanpa idempotency, memicu data ganda atau status tidak konsisten.
• Mengandalkan synchronous call untuk semua hal, membuat kegagalan berantai.
• Tidak menyiapkan dashboard operasional untuk queue lag, error rate, dan latency antar service.

Jika kesalahan-kesalahan ini masih mungkin terjadi di tim Anda, modular monolith biasanya masih pilihan yang lebih aman.

Kesimpulan

Pada ekosistem Laravel, monolith bertingkat atau modular monolith sering lebih tepat daripada microservices selama tim, domain, dan kebutuhan operasional belum menuntut pemisahan teknis yang nyata. Pendekatan ini memberi deployment yang lebih sederhana, observability yang lebih mudah, biaya operasional lebih rendah, dan maintainability yang baik jika batas modul dijaga dengan disiplin.

Microservices bukan upgrade otomatis dari monolith. Ia adalah pertukaran: Anda menukar kesederhanaan aplikasi tunggal dengan isolasi, fleksibilitas scaling, dan independensi deployment, tetapi harus membayar dengan kompleksitas distribusi. Untuk banyak admin panel, e-commerce menengah, SaaS B2B, dan sistem Laravel dengan queue berat, langkah paling sehat biasanya adalah memperbaiki struktur monolith terlebih dahulu, mengukur bottleneck nyata, lalu mengekstrak service secara bertahap hanya ketika ada alasan teknis yang kuat.