Belajar Backend Developer - Scalability & Load Balancing

#Pendahuluan

Di episode 20 kalian melindungi ketersediaan dari serangan. Sekarang pertanyaan sebaliknya: bagaimana melayani pertumbuhan yang sah? Produk yang sukses suatu saat melampaui kapasitas satu server — dan backend yang tidak dirancang untuk tumbuh akan roboh justru di momen paling penting: saat traffic naik.

Mengapa scalability penting? Karena cara sistem tumbuh menentukan biaya dan keandalan. Sistem yang hanya bisa naik dengan membeli server yang semakin besar (vertical scaling) punya langit-langit — dan harga yang naik eksponensial. Sistem yang dirancang stateless dan horizontal bisa tumbuh dengan menambah instance murah. Episode ini membangun fondasi scalability dan load balancing.

#Vertical vs Horizontal Scaling

Vertical scaling (scale-up): menambah daya satu server — CPU, memori. Sederhana, tapi ada batas fisik dan biaya melonjak.

Horizontal scaling (scale-out): menambah jumlah instance di belakang load balancer. Inilah cara sistem modern bertahan: 100 instance murah lebih tangguh dari 1 server raksasa — dan jika satu mati, yang lain tetap melayani.

#Stateless: Syarat Scaling Horizontal

Instance yang diskalakan horizontal tidak boleh menyimpan state yang bergantung pada instance tertentu. Jika user login di instance A lalu request berikutnya sampai ke instance B yang tidak tahu state-nya, sesi rusak.

Pola stateful yang menghalangi scaling:

Perbaikan: pindahkan state ke sistem eksternal:

• Sesi/token → Redis atau JWT stateless (episode 7).
• Rate limit → Redis store (episode 20).
• File → object storage (episode 16).
• In-memory data → database/cache bersama.

#Load Balancer

Load balancer membagi traffic ke beberapa instance. Tiga aspek yang wajib dipahami:

#1. Algoritma Distribusi

• Round robin — giliran rata; cukup untuk request seragam.
• Least connections — kirim ke instance paling sepi; cocok untuk request berdurasi berbeda.
• Sticky sessions — user tetap di instance yang sama; hindari — justru menciptakan stateful dan merusak tujuan load balancing.

#2. Health Check

Load balancer harus tahu instance mana yang sehat:

GET /health  # direspons oleh aplikasi
# instance yang gagal health check dikeluarkan dari rotasi otomatis

#3. Session Persistence vs Stateless

Sticky session terlihat praktis (state di memori tetap jalan), tapi membatalkan manfaat horizontal scaling: satu instance bisa kebanjiran. Solusi yang benar adalah stateless + state eksternal, bukan sticky.

#Contoh: nginx sebagai load balancer

upstream api_servers {
    least_conn;
    server api-1.internal:3000;
    server api-2.internal:3000;
    server api-3.internal:3000;
}
 
server {
    listen 80;
    location / {
        proxy_pass http://api_servers;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Cloud provider menyediakan versi managed (ALB, Cloud Load Balancer) — pakai itu di produksi (episode 16).

#Auto Scaling

Scaling tidak harus manual — auto scaling menambah/mengurangi instance berdasarkan metrik:

TargetTrackingScalingConfiguration:
  TargetValue: 60.0        # target CPU 60%
  PredefinedMetricSpecification:
    PredefinedMetricType: EC2AutoScalingAverageCPUUtilization
 
# instance bertambah saat CPU > 60%, berkurang saat idle

Prinsip penting:

• Scaling berdasarkan metrik, bukan tebakan: CPU, latency, panjang queue.
• Beri jeda cooldown agar tidak naik-turun liar (oscillation).
• Uji dengan load test sebelum event besar.

#Scaling Database

Saat aplikasi diskalakan horizontal, database jadi titik berikutnya. Empat strategi dari yang paling sederhana:

#1. Optimasi Query + Index (Episode 5, 9)

Sebagian besar "database lambat" selesai di sini tanpa scaling apa pun.

#2. Read Replica

Traffic baca (biasanya 80-90%) dialihkan ke replika:

Writes  → primary
Reads   → replica-1, replica-2, ...

#3. Cache (Episode 9)

Redis mengurangi beban database secara drastis sebelum perlu scaling.

#4. Sharding (Partisi Data)

Data dipecah per key (misal user_id % 10) ke banyak database. Terakhir — menambah kompleksitas besar: join lintas shard mustahil, dan resharding menyakitkan.

Urutan ini penting: jangan sharding sebelum yang lain habis. Mayoritas sistem cukup di tahap optimasi + replica + cache.

#Stateless dan Session: Kaitan dengan Episode Sebelumnya

Semua yang pernah kita bangun mulai saling terhubung di sini:

• JWT stateless (episode 7) — token mandiri, instance mana pun bisa verifikasi.
• Redis untuk rate limit & cache (episode 9, 20) — state bersama.
• Queue untuk pekerjaan berat (episode 10) — worker terpisah yang bisa diskalakan sendiri.
• Object storage (episode 16) — file di luar instance.
• Managed services (episode 16) — cloud yang menangani replika dan scaling.

#Common Pitfalls

#Scaling Vertikal Tanpa Batas

Menambah RAM/CPU terus menerus = biaya naik, batas fisik tercapai. Pindah ke horizontal.

#Sticky Session sebagai Pelarian

Mengandalkan sticky untuk menutupi stateful app menunda masalah — scaling jadi tidak fleksibel. Pindahkan state, bukan tempel instance.

#Health Check Tidak Ada

Load balancer tanpa health check mengirim traffic ke instance mati. /health wajib.

#Load Test Tidak Pernah

Scaling tanpa tahu kapasitas = menebak. Load test untuk menemukan titik patah (episode 25).

#Sharding Premature

Memecah database sebelum optimasi + cache habis = kompleksitas tanpa manfaat.

#Penutup

Episode 21 membuat sistem tumbuh: vertical vs horizontal scaling, prinsip stateless sebagai syarat utama, cara kerja load balancer, auto scaling berdasarkan metrik, dan strategi scaling database yang bertahap.

Inti yang harus dibawa pulang:

• Horizontal > vertical — lebih tangguh dan tidak ada batas fisik.
• Stateless adalah syarat: state dipindah ke Redis/database/storage eksternal.
• Load balancer membagi traffic + health check; hindari sticky session.
• Auto scaling berdasarkan metrik terukur, dengan cooldown dan load test.
• Database: optimasi → read replica → cache → sharding (terakhir).

Di episode 22 selanjutnya kita akan masuk pola tingkat lanjut: event-driven & streaming — Kafka, event sourcing, dan CQRS untuk sistem yang reaktif. Sampai jumpa di episode 22!