Arsitektur Monolit Inertia: Trade-off Octane vs PHP-FPM

Aplikasi monolit berbasis Inertia.js menyatukan controller Laravel dan routing frontend ke dalam satu siklus request-response tanpa lapisan API terpisah. Pada arsitektur konvensional, monolit ini berjalan di atas PHP-FPM dengan model share-nothing (stateless). Transisi ke persistent runtime menggunakan Laravel Octane (didukung FrankenPHP) menawarkan peningkatan throughput drastis dengan menjaga aplikasi tetap berada di memori antar-request, tetapi membawa konsekuensi arsitektural berupa risiko state pollution dan overhead operasional.

Karakteristik Runtime: Stateless Lifecycle vs Persistent Worker

Perbedaan mendasar antara PHP-FPM dan persistent worker terletak pada lifecycle framework dan retensi memori proses:

• PHP-FPM (Stateless): Setiap request masuk melalui web server (Nginx/Caddy), diteruskan melalui protokol FastCGI ke worker PHP-FPM. Worker melakukan bootstrap lengkap kernel framework (memuat file konfigurasi, registrasi service provider, resolusi dependency container, dan inisialisasi routing). Setelah response dikirim, seluruh alokasi memori, instance singleton, dan variabel global dimusnahkan oleh garbage collector PHP.
• Laravel Octane dengan FrankenPHP (Persistent): Worker mengeksekusi PHP via thread C/Go yang persisten. Framework di-bootstrapped sekali saat daemon dijalankan. Request yang masuk langsung dieksekusi oleh Application instance yang sudah aktif dalam RAM. Tidak ada biaya bootstrap ulang per request.

Evaluasi Trade-off: Throughput, Serialisasi Props, dan Memori

Implementasi Octane pada monolit Inertia tidak otomatis melipatgandakan performa di semua lini. Evaluasi metrik performa harus dipisahkan antara layer framework dan logic aplikasi.

1. Throughput per Core dan Framework Overhead

Pada PHP-FPM, bootstrap framework menyumbang latensi baseline sekitar 15ms hingga 35ms per request sebelum controller dieksekusi. Pada aplikasi monolit dengan banyak dependensi paket dan puluhan service provider, pemborosan CPU untuk parsing file PHP berulang sangat tinggi.

Octane mengeliminasi overhead ini. Throughput (request per second) untuk route yang mengembalikan view dasar Inertia dapat meningkat 3 hingga 5 kali lipat per core CPU karena worker langsung mengeksekusi callback routing tanpa inisialisasi kernel ulang.

2. Latensi Serialisasi Props Inertia

Inertia mengandalkan pengiriman payload JSON melalui header X-Inertia atau rendering HTML root tag saat request awal. Octane memangkas waktu sebelum serialisasi dimulai, tetapi tidak mempercepat serialisasi data itu sendiri.

Jika controller Inertia Anda memuat relasi Eloquent yang berat dan melakukan transformasi data secara lambat (misal: JSON encoding struktur nested array yang besar), latensi CPU tetap terikat pada eksekusi kode tersebut. Octane hanya mengoptimalkan siklus hidup proses HTTP, bukan kompleksitas algoritma data formatting.

3. Efisiensi vs Kebocoran Memori (Memory Leak)

PHP-FPM mengisolasi kegagalan memori secara alami: memori dibersihkan saat request selesai. Sebaliknya, worker persistent rentan terhadap akumulasi memori tak terpaksa. Static array yang terus bertambah, event listener yang didaftarkan berulang, atau uncollected circular references dapat membuat konsumsi RAM worker membengkak hingga menyentuh batas sistem (OOM crash).

Risiko State Leakage pada Monolit Inertia

Tantangan terbesar persistent worker pada monolit Inertia adalah polusi konteks pengguna antar-request (context pollution). Masalah ini terjadi ketika data request atau identitas autentikasi tersimpan dalam singleton atau property statis.

Kasus: Kebocoran Data via Shared Props

Inertia mengandalkan method Inertia::share() untuk mendistribusikan data global (seperti user login atau flash message) ke frontend. Jika middleware atau provider mendaftarkan shared data langsung pada container singleton tanpa mekanisme reset, user berikutnya berpotensi menerima state dari user sebelumnya.

// CONTOH KELIRU (Bocor di Persistent Runtime):
class ProblematicInertiaServiceProvider extends ServiceProvider
{
    public function boot(): void
    {
        // Menyimpan data request langsung ke singleton instance
        $user = auth()->user();
        Inertia::share([
            'auth' => [
                'user' => $user ? ['id' => $user->id, 'email' => $user->email] : null,
            ],
        ]);
    }
}

Pada Octane, closure atau dependency injection harus mengevaluasi context saat request diproses, bukan saat runtime booting.

// PENDEKATAN BENAR (Aman untuk PHP-FPM dan Octane):
class SafeInertiaMiddleware extends Middleware
{
    public function share(Request $request): array
    {
        return array_merge(parent::share($request), [
            'auth' => [
                // Evaluasi secara dinamis per lifecycle request
                'user' => fn () => $request->user()
                    ? $request->user()->only('id', 'name', 'email')
                    : null,
            ],
            'flash' => [
                'message' => fn () => $request->session()->get('message'),
            ],
        ]);
    }
}

Checklist Mitigasi Reset State

Gunakan checklist berikut sebelum menjalankan monolit Inertia di atas Laravel Octane:

1. Gunakan Lazy Evaluation pada Shared Props: Selalu bungkus Inertia props dinamis dalam closure fn () => ... di middleware HandleInertiaRequests agar dievaluasi tepat saat response dikompilasi.
2. Audit Service Container Binding: Hindari binding request-specific service menggunakan $this->app->singleton() jika service tersebut menyimpan internal state dari HTTP request atau auth user. Gunakan $this->app->bind() atau inject instance via method dependency injection.
3. Konfigurasi Octane Listeners: Daftarkan service provider Anda pada array flush di file config/octane.php untuk memastikan state internal dibersihkan tiap iterasi request:

'flush' => [
    App\Services\ContextStorage::class,
],

4. Tentukan Request Limit Worker: Konfigurasikan flag worker restart secara berkala untuk membuang fragmented memory secara otomatis, misalnya dengan opsi --max-requests=500 atau --max-requests=1000.

Biaya Operasional: Scale-Up vs Scale-Out

Pilihan runtime berdampak langsung pada arsitektur infrastruktur dan biaya server:

• Scale-Up (Octane / FrankenPHP): Memungkinkan utilisasi resource secara padat. Satu instance compute berukuran besar (misal: 8-16 vCPU) dapat menangani load traffic yang setara dengan cluster multi-instance PHP-FPM. Hal ini mengurangi kebutuhan load balancer internal dan menghemat biaya compute total. Namun, proses deployment membutuhkan sinyal reload khusus (octane:reload) dan kegagalan fatal pada satu worker dapat berdampak pada concurrent requests yang sedang berjalan di worker tersebut.
• Scale-Out (PHP-FPM): Sangat elastis untuk horizontal pod autoscaling (HPA) di Kubernetes atau cloud autoscaling groups. Karena worker bersifat stateless murni, deployment model rolling restart sangat stabil tanpa risiko memory leak yang menumpuk. Kelemahannya adalah baseline konsumsi CPU yang tinggi untuk framework bootstrap, sehingga membutuhkan kapasitas core yang lebih banyak untuk melayani request peak yang sama.

Matriks Keputusan

Kapan Bertahan di PHP-FPM?

• Aplikasi berorientasi internal dashboard (SaaS B2B atau internal tool) dengan concurrency moderat (< 200 concurrent requests).
• Waktu eksekusi dominan dihabiskan pada blocking I/O pihak ketiga (database query lambat atau latency external API), di mana penghematan 20ms bootstrap tidak memberi dampak bisnis yang nyata.
• Tim belum memiliki pengalaman mendalam dalam profiling static memory dan arsitektur async/persistent worker.

Kapan Beralih ke Laravel Octane?

• Aplikasi monolit Inertia melayani public-facing traffic tinggi dengan kebutuhan throughput tinggi per unit biaya server.
• Aplikasi telah teruji bebas dari penyalahgunaan static state dan singleton container.
• Tim siap mengimplementasikan observabilitas runtime yang ketat (seperti tracking memory usage per worker via Prometheus/Grafana) dan otomasi zero-downtime deployment.