Bayangin kamu buka warung kopi. Pelanggan masih dikit, satu meja kasir cukup. Eh viral di TikTok — besok antri sampe ke jalan. Kamu mesti pikirin: tambahin meja kasir, tambahin barista, jangan sampe kopi habis tengah hari. System Design = mikirin gimana app kamu bisa nangani pelanggan dari 10 jadi 10 juta tanpa ambruk.

💡 Tulis kode yang bener aja gak cukup. Kode bener tapi crash pas rame = belum siap dipake. System design = pelajaran "gimana biar gak crash pas viral".

Apa yang dipertimbangkan dalam system design:

1. Scalability — Bisa menangani pertumbuhan

Hari ini: 100 user
Bulan depan: 10.000 user
Tahun depan: 1.000.000 user

Apakah sistem kamu bisa berkembang tanpa harus ditulis ulang?

Dua jenis scaling:

• Vertical scaling (scale up) — upgrade hardware (RAM, CPU lebih besar)
• Horizontal scaling (scale out) — tambah lebih banyak server

2. Availability — Selalu tersedia Jika satu server mati, apakah sistem tetap berjalan? Target umum:

• 99.9% uptime = max ~8.7 jam down per tahun
• 99.99% uptime = max ~52 menit down per tahun

3. Reliability — Konsisten dan benar Data tidak boleh hilang. Transaksi harus complete atau tidak sama sekali. User mendapat response yang benar setiap saat.

4. Latency — Responsif

• Halaman web harus load < 2 detik
• API response harus < 200ms untuk operasi biasa
• Real-time features (chat) harus < 100ms

5. Consistency vs Availability (CAP Theorem):

Dalam distributed system, kamu hanya bisa pilih 2 dari 3:
- Consistency: semua node mengembalikan data terbaru
- Availability: setiap request mendapat response
- Partition tolerance: sistem tetap berjalan meski network terputus

Contoh trade-off:
- Bank: pilih Consistency (saldo harus akurat)
- Social media: pilih Availability (boleh sedikit delay, asal tetap bisa diakses)

Komponen umum dalam system design:

Pendekatan system design:

1. Pahami requirements — apa yang sistem harus lakukan?
2. Estimasi kapasitas — berapa user, berapa data, berapa request/detik?
3. Desain high-level — komponen apa saja yang dibutuhkan?
4. Deep dive — detail setiap komponen
5. Identifikasi bottleneck — di mana sistem bisa gagal?

System design bukan tentang menemukan "jawaban benar" — ini tentang membuat trade-off yang tepat berdasarkan kebutuhan.

🎭 Analogi sehari-hari: System design = arsitektur rumah. Mau rumah 1 lantai atau 10 lantai? Beda fondasi, beda biaya, beda kompleksitas. Programmer biasa = tukang yang bisa pasang batu bata. System designer = arsitek yang paham trade-off: beton vs kayu, tata letak ruangan, sirkulasi udara, keamanan kebakaran. Bukan tentang "bisa pasang", tapi tentang "pilih yang tepat".

💡 Skill paling penting di interview system design:

1. Klarifikasi requirements — jangan langsung gambar arsitektur, tanya dulu (functional + non-functional)
2. Estimasi kapasitas — back-of-envelope: 10jt user × 10 req/hari = 100jt req/hari ≈ 1000 req/sec
3. Identifikasi bottleneck — biasanya database, kemudian network, kemudian compute
4. Sebut trade-off explicit — "kami pilih C atas A karena..."
5. Iterasi — high-level dulu, deep dive setelah itu

⚠️ Jebakan klasik:

• Over-engineering — desain microservices untuk app 100 user. Mulai monolith, split kalau perlu
• Lupa non-functional requirements — latency, availability, durability, security
• Pilih database trendy bukan yang fit — "Pakai MongoDB karena keren" tanpa cek pattern akses
• Skip estimasi — tanpa angka, semua keputusan opini, bukan informed decision
• Asumsi infinite scale — semua sistem ada batas, tahu di mana

🎯 Pendekatan interview/desain real:

1. Functional req ("apa yang sistem harus lakukan?")
2. Non-functional req (RPS, latency, availability target)
3. Capacity estimate (storage, bandwidth, QPS)
4. High-level design (boxes & arrows)
5. Database schema + API contract
6. Deep dive 1-2 kompmonen kritikal
7. Identify bottleneck + bahas mitigation

TL;DR: System design = trade-off arsitektur untuk skala, availability, latency, consistency, cost. Bukan tentang jawaban benar, tentang pilihan tepat. Mulai dari requirements + estimasi, baru gambar arsitektur. Iterasi. Sebut trade-off.