Skalabilitas Monolit Inertia: Trade-off Redis Session vs Sticky Session

Aplikasi monolitik berbasis Inertia.js memadukan arsitektur Single Page Application (SPA) dengan kenyamanan routing dan state management di sisi server. Ketika beban trafik meningkat dan menuntut ekspansi horizontal ke beberapa compute node di balik load balancer, arsitektur session state menjadi titik krusial. Kegagalan penanganan session dapat memicu galat umum seperti HTTP 419 (Page Expired), kegagalan otentikasi, atau ketimpangan beban kerja server.

Dua pendekatan dominan untuk mengelola sesi pada monolit Inertia.js adalah Sticky Session (berbasis Application Load Balancer / ALB affinity) dan Centralized Session Storage (umumnya menggunakan Redis). Masing-masing memiliki implikasi mendasar terhadap keandalan sistem, latensi request, dan beban biaya infrastruktur.

Karakteristik Stateful Inertia.js dan Ancaman HTTP 419

Inertia.js beroperasi melalui protokol XHR standar dengan header khusus seperti X-Inertia dan X-Inertia-Version. Meskipun terasa seperti aplikasi decoupled di sisi klien, server backend (misalnya Laravel) tetap memproses request melalui middleware web tradisional yang mengevaluasi cookie session terenkripsi dan token CSRF.

Ketika sebuah request diarahkan ke node yang tidak memiliki rekaman session lokal pengguna, proses validasi token CSRF gagal. Server merespons dengan HTTP status 419. Pada SPA biasa dengan token berbasis stateless JWT, masalah ini tidak terjadi. Namun pada monolit Inertia:

• Setiap navigasi halaman atau mutasi data (POST, PUT, DELETE) mengeksekusi pemeriksaan CSRF berbasis session server.
• Perbedaan versi build aset antara node saat rolling deployment memicu Inertia merespons dengan status 409 (Conflict), memaksa browser melakukan hard refresh via request HTTP GET biasa. Jika request hard refresh mendarat di node tanpa data session, pengguna otomatis logout atau terlempar ke layar error.

Pendekatan 1: Sticky Session (Session Affinity)

Sticky session menginstruksikan load balancer (seperti AWS ALB atau NGINX) untuk mengikat koneksi browser pengguna ke satu compute node tertentu menggunakan cookie identifikasi (affinity cookie).

Keunggulan Teknis

• Zero Network Session I/O: Session file dapat disimpan di local disk atau tmpfs (RAM) node lokal. Waktu baca/tulis mendekati 0 milidetik tanpa interaksi jaringan eksternal.
• Kesederhanaan Infrastruktur: Tidak memerlukan komponen dependensi database tambahan. Arsitektur tetap ramping tanpa overhead manajemen cluster cache.

Kelemahan dan Kegagalan Operasional

• Resiliensi Rendah pada Node Failover: Jika node A mengalami Out Of Memory (OOM) atau terminasi proses, seluruh sesi aktif pada node tersebut hilang seketika. Request berikutnya dialihkan ke node B dan menghasilkan HTTP 419 pada interaksi form berikutnya.
• Traffic Polarization (Hot-spotting): Pembagian beban menjadi tidak merata. Pengguna dengan aktivitas intensif tetap terikat pada satu instance tertentu, merusak efisiensi algoritma least outstanding requests atau round-robin.
• Friksi Rolling Deployment: Saat instans lama ditarik keluar dari pool load balancer (deregistrasi), koneksi yang masih terikat dipaksa pindah ke node baru. Kecuali aplikasi mengimplementasikan sinkronisasi storage terdistribusi untuk file session, pengguna aktif akan menghadapi invalidasi session.

Pendekatan 2: Centralized Redis Session

Pada pendekatan centralized session, seluruh compute node diperlakukan secara stateless. Session data disimpan di cluster Redis yang berdiri sendiri dan diakses bersama oleh seluruh instance monolit.

Keunggulan Teknis

• Seamless Failover dan Auto-scaling: Node compute dapat diterminasi atau ditambahkan secara dinamis tanpa mengganggu status login pengguna. Jika node 1 crash, load balancer langsung mengarahkan request ke node 2 tanpa memicu HTTP 419.
• Deployment Aman: Rolling deployment berjalan mulus. Pengguna dapat berganti node pada tiap request XHR tanpa kehilangan session state atau token validasi.
• Load Balancing Murni: Load balancer mendistribusikan request secara adil berdasarkan kapasitas riil node, bukan berdasarkan riwayat koneksi.

Kelemahan dan Overhead

• Latensi Round-Trip Jaringan: Setiap request Inertia memuat middleware StartSession yang membaca data dari Redis, serta menyimpan kembali state saat terminasi request. Latensi round-trip jaringan (biasanya 0.5ms - 2ms per request di VPC lokal) ditambahkan ke setiap interaksi.
• Single Point of Failure (SPoF) Baru: Kegagalan pada cluster Redis melumpuhkan seluruh ekosistem aplikasi secara serentak. Redis wajib dikonfigurasi dengan replikasi multi-AZ dan auto-failover (Sentinel atau Redis Cluster).
• Connection Pooling dan Port Exhaustion: Pada arsitektur PHP-FPM konvensional, setiap proses pekerja (worker process) membuka koneksi TCP terpisah ke Redis. Trafik tinggi dapat memicu habisnya connection limit pada Redis.

Evaluasi Trade-off Teknis dan Biaya Operasional

Tabel berikut merangkum perbedaan operasional antara kedua pendekatan:

Implementasi Konfigurasi

1. Konfigurasi Redis Session dengan Ekstensi phpredis

Hindari penggunaan driver predis (PHP murni) pada environment produksi monolitik berskala tinggi guna memangkas latensi eksekusi. Gunakan ekstensi C phpredis dengan opsi persistent connection.

// config/database.php
'redis' => [
    'client' => env('REDIS_CLIENT', 'phpredis'),

    'options' => [
        'cluster' => env('REDIS_CLUSTER', 'redis'),
        'prefix' => env('REDIS_PREFIX', 'monolith_session_'),
    ],

    'session' => [
        'url' => env('REDIS_URL'),
        'host' => env('REDIS_HOST', '10.0.1.20'),
        'password' => env('REDIS_PASSWORD'),
        'port' => env('REDIS_PORT', '6379'),
        'database' => env('REDIS_SESSION_DB', '1'),
        'persistent' => true, // Mencegah reconnect TCP overhead pada tiap request
        'timeout' => 0.5,
    ],
],

// .env
SESSION_DRIVER=redis
SESSION_CONNECTION=session
SESSION_LIFETIME=120
REDIS_CLIENT=phpredis

2. Konfigurasi Sticky Session pada NGINX (Alternatif ALB)

Jika menggunakan reverse proxy mandiri berbasis NGINX, affinity session dapat dikonfigurasi melalui modul upstream cookie:

upstream inertia_backend {
    ip_hash; // Metode sederhana berbasis IP
    server 10.0.1.11:8000 max_fails=3 fail_timeout=10s;
    server 10.0.1.12:8000 max_fails=3 fail_timeout=10s;
}

server {
    listen 80;
    server_name app.monolith.internal;

    location / {
        proxy_pass http://inertia_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Catatan: ip_hash rentan menyebabkan imbalance jika sebagian besar pengguna berada di balik satu gateway NAT atau proxy korporat yang sama. Untuk production cloud, gunakan Application-based cookie stickiness pada cloud load balancer.

Matriks Keputusan: Kapan Beralih ke Redis Session?

Pertahankan Sticky Session jika:

• Aplikasi berada pada fase awal ekspansi (hanya 2 compute node statis).
• Frekuensi deployment rendah dan deployment terjadwal di luar jam sibuk dengan downtime maintenance singkat.
• Tim teknik belum memiliki keahlian atau anggaran untuk mengelola managed cluster database terpisah.

Segera beralih ke Centralized Redis Session jika:

• Infrastruktur menerapkan Auto-scaling Group berbasis CPU atau throughput network, di mana node compute rutin dimatikan dan dihidupkan otomatis.
• Tim menerapkan praktik Continuous Delivery dengan frekuensi rolling deployment beberapa kali sehari.
• Log error server mulai dibanjiri keluhan 419 Page Expired atau pembeli kehilangan isi keranjang belanja secara mendadak saat navigasi Inertia berlangsung.
• Aplikasi menangani ribuan concurrent users aktif yang menuntut distribusi beban murni secara proporsional di seluruh node server.