Belajar Caddy - Session Persistence & Sticky Sessions

#Pendahuluan

Episode 14 menunjukkan load balancing yang membagi request merata. Tapi ada masalah: aplikasi yang menyimpan session di memori. Jika request pertama ke instance A dan request berikutnya ke instance B, session hilang — pengguna tiba-tiba logout. Solusinya adalah sticky sessions: membuat request dari klien yang sama selalu menuju instance yang sama.

Episode 15 membahas cara Caddy menjaga session persistence: affinity berbasis cookie, IP, dan header; konfigurasi cookie yang aman; kapan sticky sessions benar-benar dibutuhkan; serta alternatif stateless yang lebih baik dalam jangka panjang.

Sticky session adalah alat yang tepat pada waktu yang tepat — tapi bukan obat untuk semua. Episode ini mengajarkan kalian memilih dengan bijak.

#Konsep Sticky Session

#Mengapa Session Persistence Diperlukan

Aplikasi stateful menyimpan data sesi pengguna di memori lokal: shopping cart, token login, data form multi-langkah. Load balancing merata justru menjadi masalah karena session tersebar antar instance.

Sticky session memastikan satu pengguna selalu terhubung ke instance yang sama, sehingga state di memori selalu ditemukan.

#Kapan Perlu dan Tidak Perlu

Perlu:

• Shopping cart tanpa shared storage.
• User session tanpa Redis.
• WebSocket dengan state di server.

Tidak perlu:

• Aplikasi stateless yang menaruh state di database atau token.
• API murni yang tidak menyimpan session.
• Aplikasi dengan shared session storage (Redis).

Jika memungkinkan, arsitektur stateless selalu lebih baik — kita bahas alternatif di akhir episode.

#Affinity Berbasis Cookie

#Mengaktifkan Cookie Affinity

Caddy menyediakan policy cookie yang menempelkan cookie ke respons dan membaca ulang saat request berikutnya:

app.example.com {
    reverse_proxy {
        to localhost:8080 localhost:8081
        lb_policy cookie
    }
}

lb_policy cookie memberi tahu Caddy untuk memakai cookie untuk affinity. Cookie disetel pada respons pertama dan dipakai untuk memilih backend di request berikutnya.

#Konfigurasi Cookie

Cookie bisa disesuaikan:

app.example.com {
    reverse_proxy {
        to localhost:8080 localhost:8081
        lb_policy cookie {
            name caddy_session
            domain example.com
            path /
            max_age 3600
            secure
            httponly
        }
    }
}

Opsi penting:

• name — nama cookie, default lb_cookie.
• secure — cookie hanya dikirim lewat HTTPS.
• httponly — cookie tidak bisa dibaca JavaScript.
• max_age — umur cookie dalam detik.
• domain dan path — scope cookie.

secure dan httponly wajib diaktifkan di produksi untuk mencegah serangan XSS dan pemindahan cookie lewat HTTP.

#Affinity Berbasis IP dan Header

#IP-Based Affinity

Tanpa cookie, Caddy bisa menambatkan berdasarkan IP klien:

app.example.com {
    reverse_proxy {
        to localhost:8080 localhost:8081
        lb_policy ip_hash
    }
}

lb_policy ip_hash memakai hash IP untuk memilih backend. Sederhana, tapi semua pengguna di belakang NAT yang sama (misalnya kantor) akan tertambat ke instance yang sama — tidak merata.

#Header-Based Affinity

Untuk kontrol yang lebih presisi, hash berdasarkan header:

app.example.com {
    reverse_proxy {
        to localhost:8080 localhost:8081
        lb_policy header {
            field X-User-ID
        }
    }
}

lb_policy header { field X-User-ID } menambatkan berdasarkan nilai header X-User-ID. Cocok jika aplikasi sudah menyediakan identifier pengguna di header.

#Strategi Affinity Lanjutan

#Consistent Hashing

Untuk penyimpanan cache yang tersebar, konsistensi hash penting: saat backend ditambah atau dihapus, hanya sebagian kecil mapping yang berubah. Caddy mendukung pola ini lewat uri_hash dan header — request yang sama selalu ke backend yang sama selama set backend stabil.

#Fallback Saat Backend Hilang

Ketika backend yang ditambatkan gagal, Caddy mengalihkan request ke backend lain dan menyetel ulang cookie. Pengguna tidak tertambat selamanya ke instance yang mati — kombinasi dengan health check (episode 16) menangani ini.

#Alternatif Sticky Session

#Shared Session Storage

Cara terbaik menghilangkan kebutuhan sticky:

• Redis: session bersama untuk semua instance.
• Database: session disimpan di PostgreSQL atau MySQL.
• Session service: sistem otorisasi terpusat (episode 18).

Dengan shared storage, load balancer bisa membagi request merata tanpa peduli state.

#Stateless dengan JWT

Arsitektur stateless menaruh semua state di token:

app.example.com {
    reverse_proxy {
        to localhost:8080 localhost:8081
        lb_policy round_robin
    }
}

Dengan JWT, request membawa semua informasi yang dibutuhkan aplikasi — tidak ada session di server. Backend bisa di-replace, ditambah, atau dihapus tanpa memengaruhi pengguna. Ini alasan utama round_robin tetap jadi pilihan default yang sehat.

#Penutup

Episode 15 membahas session persistence: konsep sticky session dan kapan dibutuhkan, affinity berbasis cookie dengan opsi secure dan httponly, affinity berbasis IP dan header, consistent hashing, serta alternatif stateless seperti shared storage dan JWT.

Inti yang harus dibawa pulang:

• Sticky session membuat satu klien selalu ke backend yang sama.
• lb_policy cookie menambatkan lewat cookie.
• Aktifkan secure dan httponly pada cookie di produksi.
• ip_hash sederhana tapi tidak merata di belakang NAT.
• Shared storage seperti Redis menghilangkan kebutuhan sticky.
• Arsitektur stateless dengan JWT paling baik untuk scaling.

Di episode 16 selanjutnya kita akan membahas failover & circuit breaking — passive health checks, active health checks dengan endpoint kustom, retry policy, pola circuit breaker, serta high availability dengan banyak instance Caddy dan load balancer eksternal. Kesiapan produksi kalian akan naik level.