Arsitektur SSR Inertia: Sidecar vs Dedicated SSR Cluster

Mengimplementasikan Server-Side Rendering (SSR) pada aplikasi berbasis Inertia.js menghadirkan tantangan arsitektural mendasar pada layer infrastruktur. Berbeda dari arsitektur Single Page Application (SPA) murni, SSR menuntut backend monolit (seperti Laravel/PHP) mengeksekusi runtime Node.js secara synchronous sebelum merespons HTTP request ke klien. Dua model deployment utama yang dapat diadopsi adalah Sidecar Container (Node.js berjalan di dalam Pod yang sama dengan PHP-FPM) dan Dedicated SSR Cluster (Node.js diisolasi ke dalam Service/Cluster Kubernetes mandiri).

1. Perbandingan Latensi Komunikasi dan Protokol Transport

Pemilihan topologi menentukan overhead latensi jaringan pada setiap cycle initial request:

Model Sidecar (Localhost / UNIX Domain Socket)

Pada model sidecar, container PHP-FPM dan container SSR Node.js berbagi network namespace yang sama di dalam satu Pod Kubernetes. Komunikasi terjadi melalui loopback interface (127.0.0.1:13714) atau shared volume menggunakan UNIX domain socket.

• Overhead jaringan: Mendekati nol (<0.5 ms). Tidak ada overhead switching router, resolusi CoreDNS internal, maupun alokasi connection tracking (conntrack) pada kernel.
• Protokol IPC: Menggunakan UNIX domain socket meniadakan pemrosesan TCP/IP stack secara penuh, memotong packet serialization dan context switching.

Model Dedicated SSR Cluster (Internal Load Balancer)

Pada model cluster terpisah, request SSR dari PHP dikirimkan melewati network fabric internal Kubernetes (Kube-Proxy/iptables/IPVS atau Cilium eBPF) menuju Service abstraction.

• Overhead jaringan: Tambahan latensi network round-trip berkisar antara 1.5 ms hingga 6 ms per SSR request tergantung kepadatan node dan topologi inter-zone AWS/GCP.
• Koneksi HTTP: Wajib mengimplementasikan HTTP keep-alive dan connection pooling pada client Guzzle/cURL di PHP. Ketiadaan pooling menyebabkan TCP handshake (SYN-ACK) berulang pada setiap render request, meningkatkan Time to First Byte (TTFB).

// config/inertia.php - Konfigurasi endpoint SSR
return [
    'ssr' => [
        'enabled' => true,
        // Sidecar: loopback atau local socket
        // 'url' => 'http://127.0.0.1:13714',
        
        // Dedicated Cluster: internal Kubernetes service DNS
        'url' => env('INERTIA_SSR_URL', 'http://inertia-ssr-service.default.svc.cluster.local:13714'),
    ],
];

2. Karakteristik Resource Footprint dan Autoscaling (HPA)

Pola konsumsi resource antara komputasi PHP (stateless, short-lived worker lifecycle) dan SSR Node.js (event-loop, memory persistent V8 runtime) sangat bertolak belakang.

Coupled Scaling pada Sidecar

Horizontal Pod Autoscaler (HPA) pada model sidecar terikat pada level Pod. Jika Pod scale-out akibat beban query database atau payload processing di PHP, container Node.js ikut tereplikasi secara linier.

• Inefisiensi Memori: Setiap instance SSR Node.js mengonsumsi baseline memory sekitar 80MB - 200MB untuk V8 isolate cache dan compiled bundle. Menjalankan 50 replika Pod backend berarti mengalokasikan 4GB - 10GB RAM hanya untuk runtime Node.js idle yang mungkin tidak menerima traffic render sebanding.
• Resource Contention: Jika V8 garbage collection (GC) mengalami spike CPU saat concurrent page rendering, worker PHP-FPM pada CPU core yang sama dapat mengalami request throttling.

Independent Autoscaling pada Dedicated Cluster

Model dedicated cluster memungkinkan pemisahan metrik autoscaling secara granular:

• Backend PHP-FPM dapat di-scale berbasis metrik throughput HTTP atau saturation worker pool.
• SSR Cluster di-scale secara mandiri via HPA berbasis CPU utilization (>70%) atau custom metrics seperti Node.js Event Loop Lag.
• Efisiensi biaya maksimal: Saat traffic aplikasi didominasi oleh API/JSON requests yang tidak memicu SSR (misal: Inertia partial reloads atau background mobile clients), cluster SSR tetap berada pada alokasi replika minimal.

# HPA spesifik untuk Dedicated SSR Cluster
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: inertia-ssr-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: inertia-ssr-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 75

3. Maintainability: CI/CD Pipeline, Sinkronisasi Versi, dan Observabilitas

Tingkat kompleksitas operasional beralih secara drastis saat memisahkan komponen SSR dari monolit.

Deployment Synchronization & Asset Drift

Tantangan kritis arsitektur dedicated cluster adalah sinkronisasi versi frontend antara manifest backend dan server render:

• Masalah Versi Desinkronisasi: Jika backend meluncurkan update komponen UI (misal: release v2.1.0) sementara rolling update pada dedicated SSR cluster masih memproses container v2.0.0, SSR server akan me-render markup DOM usang. Ketika markup mencapai browser, klien memuat client-bundle v2.1.0, memicu hydration mismatch error pada Vue atau React.
• Solusi Sidecar: Bersifat atomik secara default. Image container dibangun serentak atau disatukan dalam satu Pod manifest dengan tag image identik. Rollout PHP dan Node.js selalu sinkron 1:1.

Health Checks dan Degradation Graceful

Kegagalan proses SSR tidak boleh melumpuhkan seluruh aplikasi. Inertia secara default memiliki fallback client-side rendering jika request SSR gagal, namun penanganan health check berbeda:

• Sidecar: Liveness/readiness probe Kubernetes dapat mendeteksi crash pada container SSR dan me-restart container lokal tanpa menjatuhkan PHP worker.
• Cluster: Wajib memasang circuit breaker pada layer HTTP client PHP. Jika SSR cluster overload (503 Service Unavailable atau timeout >500ms), PHP harus langsung me-render container shell standar (SSR fallback) agar respons HTTP tetap sampai ke end-user.

4. Matriks Evaluasi Arsitektur

5. Panduan Pengambilan Keputusan

Gunakan acuan teknis berikut untuk menentukan arsitektur yang tepat:

Tetap Menggunakan Model Sidecar Jika:

• Aplikasi menggunakan alokasi node yang moderat (<15 Pod PHP-FPM).
• Tim menginginkan atomic deployment tanpa perlu mengelola pipeline koordinasi multi-service.
• Rasio request SSR terhadap total request seragam di semua endpoint halaman.
• Menghindari kompleksitas pengelolaan DNS internal, ingress controller terpisah, dan connection pooling.

Wajib Beralih ke Dedicated SSR Cluster Jika:

• Footprint pod backend besar (>30-50 Pod) sehingga duplikasi runtime Node.js membuang alokasi RAM cluster yang signifikan.
• Pola traffic sangat asimetris: sebagian besar traffic berupa API calls atau Inertia partial reloads yang tidak mengeksekusi SSR, sementara SSR hanya dipicu oleh landing page/SEO bots.
• Beban render komponen React/Vue sangat intensif komputasi (banyak chart, markdown parsing server-side) yang berisiko mencuri siklus CPU PHP-FPM.
• Tim DevOps memiliki tooling orkestrasi yang matang untuk mengontrol deployment orchestration bertahap (Canary/Blue-Green) guna mencegah hydration mismatch.