Belajar System Design - Scalability: Horizontal vs Vertical

#Pendahuluan

Setelah di episode 1 kita memahami distributed system, CAP theorem, dan identifikasi SPOF, pada episode ini kita masuk ke pertanyaan paling fundamental dalam scalability: horizontal atau vertical? Keputusan ini menentukan arsitektur seluruh sistem kalian — dari infrastruktur, biaya, hingga cara menangani kegagalan.

Bayangkan aplikasi kalian mulai melambat karena traffic meningkat. Apa yang kalian lakukan? Jawaban pertama kebanyakan engineer adalah "upgrade server." Tapi apakah itu selalu solusi terbaik? Di episode ini kita bedah keduanya secara mendalam.

#Vertical Scaling (Scale-Up)

Vertical scaling artinya upgrade hardware pada mesin yang sama: tambah CPU, RAM, atau storage.

#Kelebihan

• Mudah diimplementasikan — tidak perlu mengubah kode atau arsitektur.
• Tidak ada complexity distribusi — satu mesin, satu database, satu proses.
• Latency rendah — komunikasi intra-process tanpa network overhead.

#Kekurangan

• Hardware limit — ada batas physical: CPU paling kuat di AWS c6i.metal adalah 128 vCPU, RAM maksimal 1TB.
• Single point of failure — satu mesin = satu titik kegagalan.
• Cost meningkat non-linear — upgrade dari 32GB ke 64GB RAM murah; dari 512GB ke 1TB sangat mahal.
• Downtime saat upgrade — beberapa cloud provider memerlukan restart untuk resize instance.

#Kapan Vertical Scaling Masuk Akal

• Database relasional yang sulit di-shard (PostgreSQL/MySQL).
• Aplikasi yang membutuhkan strong consistency (single leader).
• Traffic masih dalam skala satu mesin (startups kecil-menengah).
• Development/testing environment.

#Horizontal Scaling (Scale-Out)

Horizontal scaling artinya menambah lebih banyak mesin di belakang load balancer.

#Kelebihan

• Theoretically unlimited — tambah server terus, tidak ada batas hardware.
• Fault tolerance — jika satu server mati, yang lain mengambil alih.
• Cost linear — harga proporsional dengan kapasitas.
• Zero-downtime scaling — tambah server tanpa restart aplikasi yang berjalan.

#Kekurangan

• Complexity — butuh stateless design, session management, data replication.
• Network overhead — komunikasi antar server lebih lambat dari intra-process.
• Data consistency — menjaga data konsisten di banyak server membutuhkan replikasi dan consensus.
• Operational overhead — monitoring, deployment, debugging lebih kompleks.

#Persyaratan Horizontal Scaling

Untuk bisa horizontal scale, aplikasi harus:

1. Stateless — tidak menyimpan session di memory server; gunakan Redis/DB untuk session.
2. Database scalable — replication, sharding, atau database managed yang auto-scale.
3. Load balancer — distribusi traffic merata ke semua server.

#Load Balancing Algorithm

Load balancer bertugas mendistribusikan request ke backend server. Beberapa algoritma utama:

#Round-Robin

Setiap request dikirim ke server berikutnya secara bergiliran.

Request 1 → Server A
Request 2 → Server B
Request 3 → Server C
Request 4 → Server A (balik ke awal)

Kelebihan: sederhana, adil. Kekurangan: tidak mempertimbangkan beban aktual server.

#Least Connections

Request dikirim ke server dengan paling sedikit koneksi aktif.

Kelebihan: lebih adil untuk beban aktual. Kekurangan: butuh tracking koneksi aktif, overhead lebih tinggi.

#IP Hash

Hash IP client menentukan server tujuan — client yang sama selalu ke server yang sama.

Kelebihan: sticky session tanpa cookie. Kekurangan: uneven distribution jika hash tidak uniform.

#Weighted Round-Robin

Round-robin dengan bobot: server lebih kuat menerima lebih banyak request.

Server A (weight 3): menerima 3 dari 6 request
Server B (weight 2): menerima 2 dari 6 request
Server C (weight 1): menerima 1 dari 6 request

#Health Check

Load balancer secara berkala mengecek apakah server backend hidup. Jika server gagal health check, traffic dialihkan ke server lain.

# HTTP health check
curl -f http://server:8080/health || echo "Server down"
 
# TCP health check
nc -zv server 8080

#L4 vs L7 Load Balancer

#Kapan Pakai Mana

• L4: TCP services (database, Redis), UDP services (gaming, VoIP), high-throughput yang tidak butuh content-based routing.
• L7: Web applications, REST APIs, microservices yang butuh path-based routing (/api/* ke service A, /web/* ke service B).

#Praktik: Desain Load Balancing

Desain load balancing untuk 3 server API:

#Opsi A: Stateless (Recommended)

Semua server stateless — session disimpan di Redis. Load balancer bisa pakai round-robin atau least connections.

#Opsi B: Sticky Session

Client yang sama selalu ke server yang sama. Problem: jika server mati, semua session di server itu hilang.

#Perbandingan

#Penutup

Inti yang harus dibawa pulang:

• Vertical scaling mudah tapi punya limit hardware; horizontal scaling scalable tapi kompleks.
• Load balancing algorithm: round-robin (sederhana), least connections (adil), IP hash (sticky), weighted (flexible).
• L4 vs L7: L4 untuk TCP/UDP murni (cepat), L7 untuk HTTP (fitur lengkap).
• Untuk production, selalu arahkan ke stateless architecture dengan session store external.

Di episode 3 selanjutnya kita akan membahas caching strategies — browser cache, CDN edge cache, application cache (Redis/Memcached), database query cache, serta pola cache-aside, read-through, write-through, dan write-behind. Pastikan konsep scalability sudah dipahami, karena caching adalah salah satu teknik paling powerful untuk meningkatkan performa!