Inertia di Serverless vs Container: Trade-off Biaya, Skala, dan Cold Start

Memilih arsitektur deployment untuk aplikasi berbasis Inertia.js sering kali berujung pada perdebatan antara kesederhanaan operasional serverless (seperti AWS Lambda via Laravel Vapor) dan stabilitas runtime berbasis container (Docker di AWS ECS atau Kubernetes). Inertia.js bertindak sebagai jembatan yang menggabungkan backend monolitik dengan frontend berbasis komponen SPA (Vue, React, atau Svelte). Struktur monolitik modern ini membawa karakteristik unik pada layer infrastruktur, terutama saat menangani routing hybrid, SSR (Server-Side Rendering), dan koneksi basis data.

Cold Start dan SSR: Karakteristik Runtime Inertia

Inertia membagi request menjadi dua tipe: full-page visit pertama yang mengembalikan payload HTML dasar, dan navigasi internal (XHR) yang mengirimkan header X-Inertia: true untuk mengembalikan respons JSON. Perbedaan perilaku ini berdampak langsung pada latency cold start di berbagai runtime.

1. Cold Start pada Serverless (AWS Lambda)

Pada eksekusi serverless berbasis AWS Lambda, cold start terjadi ketika instance runtime baru harus diinisialisasi untuk melayani request yang datang saat traffic melonjak atau setelah periode idle. Tantangan teknis meningkat signifikan jika Anda mengaktifkan Server-Side Rendering (SSR).

• Tanpa SSR: Runtime PHP (misal via runtime kustom Bref atau Laravel Vapor) harus meng-uncompress container image atau ZIP layer, mengeksekusi bootstrap framework (Laravel service providers), dan me-render template Blade awal. Cold start umumnya berkisar antara 250ms hingga 800ms.
• Dengan SSR: Backend monolit tidak dapat mengeksekusi JavaScript secara native. Lambda harus memicu proses Node.js lokal atau memanggil Lambda function Node.js terpisah untuk mengeksekusi bundle SSR. Skenario pemanggilan ganda ini berisiko memicu cascading cold start: cold start pada Lambda PHP ditambah cold start pada Lambda Node.js.

Konfigurasi типикал pada vapor.yml memisahkan environment SSR ke dalam function dedicated untuk mengisolasi beban eksekusi:

id: 12345
name: inertia-monolith
environments:
  production:
    runtime: 'php-8.3:al2'
    memory: 1024
    cli-memory: 512
    ssr: true
    ssr-memory: 1024
    database: production-db
    network:
      - subnet-xxxxxx
      - subnet-yyyyyy

2. Stabilitas Latency pada Container (ECS / Kubernetes)

Pada model container, aplikasi berjalan secara persisten di memori. Menggunakan server aplikasi seperti Nginx yang dipasangkan dengan PHP-FPM, atau application runner berbasis memory-resident seperti Laravel Octane (FrankenPHP atau Swoole), bootstrap framework hanya dilakukan sekali saat container start.

Untuk SSR di container, daemon Node.js dijalankan berdampingan (sidecar container atau proses lokal yang dikelola supervisor) pada loopback interface (127.0.0.1:13714). Request SSR Inertia diselesaikan via internal socket atau HTTP call lokal dengan overhead latency di bawah 5ms tanpa risiko cold start.

# Supervisord snippet untuk menjalankan Node SSR di dalam container yang sama
[program:inertia-ssr]
command=node /var/www/html/bootstrap/ssr/ssr.js
autostart=true
autorestart=true
user=www-data
redirect_stderr=true
stdout_logfile=/var/log/inertia-ssr.log

Database Connection Pooling: RDS Proxy vs PgBouncer

Aplikasi web monolitik konvensional membuka koneksi database per request. Perbedaan siklus hidup proses antara serverless dan container menentukan strategi manajemen koneksi basis data.

Kebutuhan RDS Proxy pada Serverless

AWS Lambda melakukan scaling horizontal secara cepat dengan melipatgandakan worker instance. Jika terjadi burst 1.000 concurrent request, 1.000 Lambda execution context akan aktif dan masing-masing membuka koneksi ke database. Ini dapat dengan cepat menghabiskan max_connections pada MySQL atau PostgreSQL.

Solusinya adalah menempatkan AWS RDS Proxy di depan instance database. RDS Proxy mempertahankan pool koneksi persisten ke database engine dan mengizinkan ribuan instance Lambda berbagi pool tersebut. Namun, pendekatan ini memiliki trade-off:

• Tambahan Biaya: RDS Proxy ditagih per vCPU jam dari instance database target (sekitar $0.015 - $0.018 per vCPU-hour tergantung region).
• Tambahan Latency: Menambahkan hop jaringan di dalam VPC yang menghasilkan overhead rata-rata 2ms hingga 8ms per query/transaksi.
• Pinning: Operasi tertentu (seperti prepared statements tertentu atau manipulasi locking table) dapat menyebabkan connection pinning, mengurangi efisiensi multiplexing proxy.

PgBouncer dan Local Pooling pada Container

Container memiliki jumlah worker yang dapat diprediksi. Deployment ECS Fargate dengan 4 task, masing-masing menjalankan 10 worker PHP-FPM, hanya akan membuka maksimal 40 koneksi konkuren ke database. Jika throughput sangat tinggi, PgBouncer dapat dipasang sebagai sidecar container atau service di dalam private subnet tanpa biaya managed service tambahan seperti RDS Proxy.

Asset Handling: S3 + CDN vs Reverse Proxy Nginx

Inertia.js menggunakan mekanisme asset versioning via Inertia::version(). Ketika frontend mendeteksi build hash baru dari header respons backend, Inertia melakukan hard reload untuk memuat script bundle terbaru.

Serverless (S3 & CloudFront)

Pada arsitektur serverless, asset statis hasil build (Vite/Webpack JS, CSS, chunk files) tidak disimpan di dalam Lambda layer karena batasan ukuran paket. Asset diunggah ke AWS S3 bucket saat proses deployment dan didistribusikan melalui CloudFront CDN.

• Keunggulan: Offload total traffic statis dari application layer; download asset tidak membebani komputasi backend.
• Mitigasi Deployment Mismatch: Karena deploy serverless memakan waktu singkat, client yang sedang membuka versi lama harus tetap dapat mengakses chunk lama. Bucket S3 harus mempertahankan file dari beberapa build sebelumnya agar user tidak mengalami crash ChunkLoadError sebelum reload selesai.

Container (Nginx Sidecar atau Local Asset)

Pada container, static assets dapat dibungkus langsung ke dalam Docker image dan disajikan oleh reverse proxy Nginx yang berjalan di task yang sama:

server {
    listen 80;
    root /var/www/html/public;

    index index.php;

    location /build/ {
        # Cache immutable assets hasil hashing Vite
        expires 1y;
        add_header Cache-Control "public, immutable";
        try_files $uri =404;
    }

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        include fastcgi_params;
    }
}

Model ini memungkinkan container menyajikan seluruh aplikasi secara mandiri tanpa ketergantungan deployment pipeline ke object storage eksternal, meski CDN (seperti Cloudflare) tetap direkomendasikan di layer terdepan untuk global caching.

Model Biaya Operasional (TCO)

Analisis Total Cost of Ownership (TCO) bergantung sepenuhnya pada pola lalu lintas sistem.

1. Pola Beban Idle / Rendah

Serverless unggul mutlak dari sisi efisiensi biaya saat aplikasi jarang menerima request. Biaya komputasi Lambda turun mendekati $0. Anda hanya membayar dependensi persisten seperti instance RDS, NAT Gateway, dan domain endpoint. Sebaliknya, container di ECS Fargate atau node Kubernetes mengharuskan minimal 1 atau 2 task aktif sepanjang waktu untuk high availability (HA), menciptakan baseline cost tetap setiap bulan.

2. Pola Spiky / Bursty Traffic

Untuk traffic yang tidak dapat diprediksi secara ekstrem (misalnya sistem flash-sale tiket atau pengumuman serentak), serverless mampu melakukan scaling ribuan concurrent execution context dalam hitungan detik. Container berbasis horizontal pod/task autoscaling (HPA) membutuhkan waktu 1-3 menit untuk provisioning node atau task baru, yang berisiko menyebabkan antrean request (HTTP 504 / 502) jika spike terlalu tajam.

3. Pola High-Throughput Stabil (24/7 Sustained Load)

Ketika aplikasi melayani ratusan juta request per bulan secara konstan, serverless menjadi jauh lebih mahal. Biaya API Gateway/ALB, gigabyte-second Lambda, dan RDS Proxy terakumulasi linier terhadap volume request. Pada skala ini, dedicated container instances (seperti Fargate Reserved Instances atau EKS dengan EC2 Spot/Savings Plans) jauh lebih hemat secara unit cost per request.

Matriks Komparasi Teknis

Panduan Pengambilan Keputusan

Pilih Serverless (Vapor / Lambda) jika:

• Tim engineering memiliki kapasitas DevOps minimal atau solopreneur yang ingin fokus pada delivery kode aplikasi.
• Traffic aplikasi didominasi siklus idle panjang dengan spike sesekali (misalnya aplikasi internal B2B atau portal administrasi tertentu).
• Anda tidak menggunakan fitur persistent state di memori dan seluruh logic frontend SSR dapat di-cache secara agresif di edge.

Pilih Container (ECS / Kubernetes) jika:

• Aplikasi memiliki baseline traffic yang tinggi dan stabil secara 24/7.
• SLA latency aplikasi sangat ketat; cold start di atas 200ms tidak dapat ditoleransi oleh use-case bisnis Anda.
• Anda menggunakan framework modern seperti Laravel Octane dengan FrankenPHP/Swoole untuk mengejar throughput maksimal tanpa overhead bootstrap per-request.
• Kebutuhan SSR Inertia sangat berat dan membutuhkan optimasi caching render internal secara lokal di memory aplikasi.