System Design Roadmap Part 2: Komponen Inti Skalabilitas – Load Balancers, CDN, Redis, API Gateway, Database & Kafka

Pendahuluan: Teka-Teki Skalabilitas Sistem

Pada Part 1: Fondasi Jaringan, kita telah memahami bagaimana deretan paket data melintasi internet. Namun, apa yang terjadi ketika server backend tunggal Anda yang awalnya melayani 50 request per detik (RPS) tiba-tiba dihantam lonjakan trafik menjadi 500.000 RPS?

Satu server fisik berspesifikasi dewa sekalipun (Vertical Scaling / Scale Up) pada akhirnya akan membentur batas fisik perangkat keras: batas socket CPU, kapasitas bus memori RAM, dan risiko fatal titik kegagalan tunggal (Single Point of Failure / SPOF). Untuk bertahan di skala web modern, sistem harus diskalakan secara horizontal (Scale Out) dengan merangkai komponen-komponen mandiri yang saling terhubung secara fleksibel (loosely coupled).

Dalam panduan ini, kita akan mengupas tuntas 6 komponen inti (core building blocks) yang wajib Anda kuasai untuk merancang arsitektur sistem berskala jutaan pengguna.

1. Load Balancer: Mendistribusikan Trafik & Mengeliminasi SPOF

Load Balancer (LB) bertindak sebagai pemandu lalu lintas yang berada di antara pengguna dan klaster server backend. Tugas utamanya adalah membagi beban request yang masuk secara merata agar tidak ada satu server pun yang kewalahan (overload).

Perbedaan Layer 4 (Transport) vs. Layer 7 (Application) Load Balancing

Salah satu topik terfavorit yang paling sering ditanyakan interviewer adalah perbedaan mendalam antara L4 dan L7:

Algoritma Routing Beban Populer

1. Round Robin: Membagikan request secara bergiliran ke setiap server. Sangat efektif jika seluruh node server memiliki spesifikasi perangkat keras yang seragam dan durasi proses request cenderung sama.
2. Weighted Round Robin: Memberikan porsi request lebih besar kepada mesin server yang memiliki spesifikasi CPU dan RAM lebih tinggi.
3. Least Connections: Mengarahkan request baru ke server yang saat itu memiliki jumlah koneksi aktif paling sedikit. Sangat ideal untuk request berdurasi panjang atau koneksi persistent seperti WebSocket.
4. IP Hash / Consistent Hash: Mengubah IP address pengguna menjadi nilai hash untuk menentukan server tujuan. Menjaga agar user selalu diarahkan ke server yang sama (berguna untuk session lokal, meskipun arsitektur modern lebih disarankan stateless).

Ketersediaan Tinggi (High Availability) Load Balancer Itu Sendiri

Pertanyaan jebakan wawancara: "Jika semua trafik masuk melewati Load Balancer, bukankah Load Balancer itu sendiri menjadi Single Point of Failure (SPOF)?"

Solusi Arsitektural: Gunakan sepasang Load Balancer dengan konfigurasi Active-Passive atau Active-Active menggunakan protokol VRRP (Virtual Router Redundancy Protocol) atau Keepalived. Kedua load balancer berbagi satu Virtual IP (VIP) yang sama. Node Passive secara berkala mengirim sinyal detak jantung (heartbeat) ke node Active. Jika node Active mati mendadak, node Passive akan mengambil alih VIP tersebut dalam hitungan milidetik secara transparan.

2. CDN (Content Delivery Network): Caching Tepi Global & Latensi Rendah

CDN adalah jaringan global server tepi (Point of Presence / PoP) yang menyimpan salinan aset statis dan semi-statis (gambar, video, bundle JS/CSS, font, file HTML, respons API) sedekat mungkin dengan lokasi fisik pengguna.

Tanpa CDN:  [User di Jakarta] ─── (240ms RTT) ───► [Origin Server di Virginia, AS]
Dengan CDN: [User di Jakarta] ─── (12ms RTT)  ───► [CDN Edge PoP di Jakarta]

Arsitektur Push vs. Pull CDN

Strategi Lanjutan CDN:

• Origin Shielding: Lapisan perantara (caching layer intermediate) di antara PoP tepi dunia dan data center origin Anda. Jika puluhan server tepi di Asia mengalami cache miss bersamaan, mereka bertanya ke Origin Shield regional (misal di Singapura), bukan membombardir server utama Anda.
• Invalidasi Cache: Diatur melalui header HTTP Cache-Control: public, max-age=31536000, immutable. Cara terbaik memperbarui aset statis di era modern bukanlah dengan melakukan pembersihan cache manual (purge CDN), melainkan dengan teknik content hashing pada nama file build (main.98ab4c.js).

3. Caching (Redis): Mengakselerasi Pembacaan Data dengan Memori RAM

Memori RAM bekerja 1.000 hingga 10.000 kali lebih cepat dibandingkan media penyimpanan disk fisik (NVMe SSD). Lapisan cache dalam memori seperti Redis atau Memcached bertugas mencegat request pembacaan data sebelum menyentuh database relasional, memangkas latensi hingga ke level milidetik tunggal.

Jebakan Cache di Lingkungan Produksi & Solusinya

1. Cache Stampede / Thundering Herd:
   • Masalah: Kunci cache untuk data yang sangat populer (misalnya produk diskon kilat) tiba-tiba kedaluwarsa (expired). 10.000 thread pengguna secara serentak mendeteksi cache kosong dan bersama-sama menembakkan 10.000 kueri SQL identik ke database, melumpuhkan database seketika.
   • Solusi: Pasang Distributed Mutex Lock di Redis (SET key value NX PX 5000) sehingga hanya 1 proses pekerja yang diizinkan mengambil data ke DB dan mengisi ulang cache, atau gunakan algoritma Probabilistic Early Expiration (XFetch).
2. Cache Avalanche:
   • Masalah: Ribuan kunci cache disetel dengan durasi TTL yang persis sama (misalnya 3600 detik). Pada menit ke-60, seluruh cache tersebut hangus secara serentak, menumpahkan banjir trafik ke database.
   • Solusi: Berikan nilai acak (Jitter) pada konfigurasi TTL (TTL = 3600 + rand(-300, 300)).
3. Cache Penetration:
   • Masalah: Peretas sengaja meminta ID yang sama sekali tidak ada di database (/users/-99999). Cache tidak pernah menemukan nilainya, memaksa database terus-menerus melakukan pencarian sia-sia.
   • Solusi: Simpan nilai null di cache dengan TTL singkat (misal 60 detik), atau tempatkan Bloom Filter di depan cache untuk memblokir kunci yang terbukti tidak ada secara instan.

4. API Gateway: Pengatur Lalu Lintas Tunggal Microservice

API Gateway adalah server proxy tunggal yang menjadi gerbang utama (single point of entry) bagi seluruh aplikasi client sebelum request diteruskan ke klaster microservice internal.

Tugas Utama API Gateway:

1. Otentikasi & Keamanan Terpusat: Memverifikasi tanda tangan kriptografi token JWT dan izin akses pengguna sebelum request menyentuh service downstream. Microservice internal cukup menerima header identitas yang sudah bersih (X-User-Id: 42).
2. Rate Limiting: Melindungi resource backend dari spammer dan bot scraping menggunakan algoritma cerdas seperti Token Bucket yang didukung penyimpanan Redis.
3. Terminasi SSL: Menyerap beban enkripsi HTTPS di tepi terluar, sehingga lalu lintas komunikasi antarservice di dalam jaringan privat VPC dapat berjalan via protokol HTTP/gRPC berkecepatan tinggi tanpa beban enkripsi berulang.
4. Pola Backend-For-Frontend (BFF): Menyesuaikan payload khusus untuk perangkat client yang berbeda (misal merangkum 4 panggilan API menjadi 1 payload terkompresi khusus perangkat mobile).

5. Database (SQL vs. NoSQL): Memilih Model Penyimpanan yang Tepat

Database adalah komponen yang paling menantang untuk diskalakan secara horizontal karena database memegang status data permanen (persistent state). Salah memilih tipe database di awal arsitektur akan menimbulkan biaya refactoring yang sangat masif di masa depan.

Matriks Taksonomi NoSQL

Mekanisme Indexing: B-Tree vs. LSM-Tree

• B-Trees / B+ Trees (PostgreSQL, MySQL InnoDB): Data diatur dalam halaman hierarki yang seimbang. Sangat cepat untuk pencarian titik spesifik dan kueri jangkauan rentang (range queries), namun membutuhkan operasi random disk I/O untuk menyeimbangkan kembali struktur pohon saat penulisan data baru.
• LSM-Trees (Log-Structured Merge-Trees) (Cassandra, RocksDB): Seluruh operasi tulis data baru selalu ditambahkan secara sekuensial ke memori MemTable dan commit log, sebelum secara bertahap dibuang ke file disk SSTables. Memberikan performa penulisan (write throughput) yang luar biasa cepat, dengan konsekuensi proses baca sedikit lebih lambat.

6. Message Queues & Event Streaming: Decoupling Sistem dengan Kafka

Komunikasi sinkron via HTTP (Service A -> Service B -> Service C) memiliki risiko fatal berupa Kegagalan Berantai (Cascading Failure). Jika Service C melambat hingga 5 detik atau mati total, thread pool HTTP pada Service A akan terkuras habis dan ikut tumbang.

Pesan asinkron memisahkan ketergantungan antarservice baik dari segi waktu maupun ruang.

KOMUNIKASI SINKRON (Tergantung Erat, Rentan Tumbang):
[ Checkout ] ──HTTP POST──► [ Payment ] ──HTTP POST──► [ Notifikasi ] ──► [ Inventory ]
(Jika service Notifikasi down, seluruh proses Checkout gagal!)

KOMUNIKASI ASINKRON (Terpisah Mandiri, Sangat Tangguh):
[ Checkout ] ──► [ Payment ] ──► Menerbitkan event "OrderCreated" ke [ Kafka Topic ]
                                                                           │
                                     ┌─────────────────────────────────────┼─────────────────────────┐
                                     ▼                                     ▼                         ▼
                             [ Service Notifikasi ]                [ Service Gudang ]       [ Service Analisis ]

Perbedaan Antrean Tradisional (RabbitMQ) vs. Event Log Terdistribusi (Kafka)

Konsep Esensial Kafka dalam Wawancara:

1. Topic: Kategori atau kanal tempat pesan diterbitkan.
2. Partition: Setiap topik dipecah menjadi beberapa partisi yang disebar di seluruh broker klaster. Partisi adalah commit log yang hanya bisa ditambah di akhir (append-only).
3. Jaminan Urutan Pesan: Kafka hanya menjamin urutan pesan yang mutlak di dalam satu partisi yang sama, BUKAN antarmultipartisi. Untuk menjaga urutan riwayat suatu entitas (misalnya seluruh status pesanan milik Customer #101), gunakan ID entitas tersebut sebagai Message Key Kafka.
4. Consumer Groups: Beberapa instance konsumen dapat membaca data dari satu topik yang sama secara paralel. Setiap partisi hanya akan dialokasikan ke tepat satu konsumen di dalam kelompok tersebut, memungkinkan penskalaan konsumsi data secara horizontal.

Sintesis Arsitektur: Bagaimana Semua Komponen Bekerja Sama

Inilah gambaran nyata bagaimana keenam komponen ini berkolaborasi saat jutaan pengguna berbelanja:

1. Pengguna menekan tombol "Bayar Pesanan" di aplikasi mobile.
2. Anycast DNS mengarahkan lalu lintas ke Load Balancer regional terdekat (L4 NLB).
3. NLB meneruskan koneksi TCP ke Application Load Balancer (ALB / Envoy L7).
4. ALB melakukan terminasi sertifikat SSL dan meneruskan ke API Gateway.
5. API Gateway memvalidasi token JWT user, mengecek kuota rate limiting di Redis,
   lalu meneruskan request ke Service Order.
6. Service Order memperbarui database PostgreSQL dengan transaksi ACID ketat.
7. Service Order menghapus cache keranjang belanja pengguna di Redis.
8. Service Order menerbitkan event "OrderPlaced" ke topik Apache Kafka.
9. Service Notifikasi, Service Deteksi Penipuan, dan Data Lake Analisis
   mengonsumsi event Kafka tersebut secara mandiri di belakang layar tanpa
   menambah latensi respons ke aplikasi pengguna sama sekali!

Langkah Selanjutnya di Part 3

Kini Anda telah menguasai 6 pilar arsitektur sistem berskala besar. Namun, bagaimana jika database relasional Anda sudah terlampau besar untuk disimpan dalam satu mesin fisik, atau bagaimana sistem harus bersikap ketika kabel bawah laut putus dan memicu partisi jaringan?

Pada Part 3: Pola & Konsep Terdistribusi, kita akan menyelami:

• Teorema CAP & PACELC (Memahami trade-off nyata sistem terdistribusi)
• Consistent Hashing (Hash ring, virtual nodes, dan rebalancing tanpa downtime)
• Database Sharding (Strategi range-based, hash-based, dan tantangan resharding)
• Pola Idempotensi (Mencegah transaksi ganda di jaringan yang rentan gangguan)
• Pola Desain Terdistribusi (Transactional Outbox, Saga Pattern, dan CQRS)
• Algoritma Rate Limiting (Token Bucket, Leaky Bucket, Sliding Window Log/Counter)