Load Balancer mendistribusikan traffic masuk ke beberapa server agar tidak ada satu server yang kelebihan beban.

Tanpa load balancer:

10.000 requests → Server tunggal (overload → crash!)

Dengan load balancer:

10.000 requests → Load Balancer → Server 1 (~3.333 req)
                                → Server 2 (~3.333 req)
                                → Server 3 (~3.334 req)

Algoritma load balancing:

1. Round Robin Request dikirim bergiliran: Server 1 → Server 2 → Server 3 → Server 1 → ... Sederhana tapi tidak mempertimbangkan beban masing-masing server.

2. Weighted Round Robin Server yang lebih powerful mendapat lebih banyak traffic:

• Server 1 (8 CPU): bobot 3 → dapat 3 dari setiap 6 request
• Server 2 (4 CPU): bobot 2 → dapat 2 dari setiap 6 request
• Server 3 (2 CPU): bobot 1 → dapat 1 dari setiap 6 request

3. Least Connections Request dikirim ke server yang saat ini menangani koneksi paling sedikit. Bagus untuk request yang durasinya bervariasi.

4. IP Hash Hash dari IP client menentukan server mana yang menangani. Request dari IP yang sama selalu ke server yang sama (session affinity).

5. Random Pilih server secara acak. Sederhana dan surprisingly effective.

Jenis load balancer:

L7 lebih fleksibel — bisa routing berdasarkan path:

/api/* → API servers
/images/* → Static file servers
/admin/* → Admin servers

Health Checks: Load balancer secara berkala memeriksa apakah server masih hidup:

Load Balancer → GET /health → Server 1 (200 OK ✓)
Load Balancer → GET /health → Server 2 (200 OK ✓)
Load Balancer → GET /health → Server 3 (timeout ✗) → hapus dari pool

Jika server mati, load balancer otomatis berhenti mengirim traffic ke server tersebut.

High Availability: Load balancer sendiri bisa menjadi single point of failure. Solusi: gunakan redundant load balancer (active-passive pair):

       ┌─── LB Primary (active) ───→ Servers
Client ─┤   (heartbeat ↕)
       └─── LB Secondary (standby) ─→ Servers

Jika primary mati, secondary otomatis mengambil alih (failover).

Tools:

• Nginx — reverse proxy + load balancer, sangat populer
• HAProxy — dedicated load balancer, performa tinggi
• AWS ALB/NLB — managed load balancer di cloud
• Cloudflare — load balancing + CDN + security

Sticky sessions (session affinity): Jika menggunakan session-based auth, request dari user yang sama harus selalu ke server yang sama. Alternatif yang lebih baik: simpan session di Redis (shared store) agar server manapun bisa menangani.

🎭 Analogi sehari-hari: Loket bank. Tanpa LB = 1 loket layani semua, antrian panjang. Dengan LB = ada manager yang arahkan pelanggan ke loket kosong. Round Robin = giliran teratur. Least Connections = arahkan ke loket yang antriannya pendek. Health check = manager cek loket yang masih buka.

💡 Sticky sessions = scaling killer: Sekali user "stuck" di server A, kalau A mati, session hilang. Lebih baik: state di Redis/DB shared, server manapun bisa handle. Sticky session = leftover dari era stateful, hindari kalau bisa.

⚠️ Jebakan umum:

• LB sebagai SPOF (single point of failure) — wajib redundant LB pair atau managed (ALB)
• Lupa health check = traffic terus dikirim ke server mati, user dapat error
• Session di server bukan Redis = sticky session jadi mandatory = scaling rusak
• L4 padahal butuh routing by URL path — pakai L7
• No graceful drain — server di-kill saat masih handle request → user dapet error 502

🎯 Pilih algoritma LB:

• Server homogen, request seragam → Round Robin
• Server heterogen → Weighted Round Robin
• Request durasi bervariasi (long-polling, websocket) → Least Connections
• Butuh session affinity tanpa shared store → IP Hash (last resort)
• Default startup project → Round Robin (simpel, biasanya cukup)

TL;DR: Load Balancer = distribusi traffic supaya tidak overload + redundancy. Algoritma sesuai workload. Wajib health check + LB redundant. Hindari sticky session, pakai shared session store. L4 cepat, L7 fleksibel.