Belajar System Design - Pengenalan Distributed System
Memahami perbedaan monolith vs distributed system, kenapa distribusi diperlukan untuk scale dan reliability, konsep single point of failure, serta CAP theorem yang menjadi trade-off fundamental dalam setiap desain sistem terdistribusi
#Pendahuluan
Setelah di episode 0 kita membangun mental model system design dan melatih estimasi back-of-envelope, pada episode ini kita masuk ke fondasi paling kritis: distributed system. Hampir semua sistem modern yang kita gunakan — Google, Netflix, Shopee, Tokopedia — adalah distributed system. Memahami konsep dasarnya adalah kunci sebelum kita bisa merancang sistem yang reliable di skala besar.
Mengapa distributed system penting? Karena satu mesin punya batas: CPU, RAM, storage, dan bandwidth. Saat traffic melebihi kapasitas satu mesin, kalian harus mendistribusikan beban ke banyak mesin. Tapi distribusi membawa masalah baru: bagaimana menjaga data konsisten? Bagaimana jika satu mesin mati? Bagaimana latency antar data center? Inilah yang membuat system design menjadi disiplin yang menarik dan kompleks.
#Monolith vs Distributed System
#Monolith
Monolith adalah arsitektur di mana seluruh aplikasi berjalan sebagai satu unit tunggal: satu codebase, satu deployment, satu proses.
Kelebihan monolith:
- Sederhana — satu codebase, satu deployment pipeline.
- Latency rendah — fungsi dipanggil langsung dalam proses yang sama, tanpa network overhead.
- Mudah di-debug — stack trace utuh, satu log stream.
Kekurangan monolith:
- Scaling terbatas — harus scale seluruh aplikasi, bukan bagian yang paling sibuk.
- Deployment risk — perubahan kecil bisa mempengaruhi seluruh sistem.
- Technology lock-in — seluruh stack harus konsisten.
#Distributed System
Distributed system adalah kumpulan komponen yang berjalan di mesin berbeda dan berkomunikasi lewat jaringan untuk mencapai tujuan bersama.
Kelebihan distributed:
- Scalability — scale komponen yang sibuk secara independen.
- Reliability — jika satu mesin mati, yang lain bisa mengambil alih.
- Geo-distribution — dekatkan layanan ke pengguna di berbagai wilayah.
Kekurangan distributed:
- Complexity — network bisa gagal, data bisa inconsistent, debugging sulit.
- Latency — komunikasi antar mesin lebih lambat dari intra-process.
- Operational overhead — lebih banyak yang harus dimonitor, di-deploy, di-maintain.
#Kenapa Harus Distribusi
Tiga alasan utama organisasi memilih distribusi:
| Alasan | Penjelasan | Contoh |
|---|---|---|
| Scale | Satu mesin tidak cukup untuk traffic besar | YouTube: 115K QPS tidak bisa ditangani satu server |
| Reliability | Jika satu mesin mati, sistem tetap jalan | Bank: zero downtime tolerance |
| Geo | Pengguna tersebar secara geografis | Netflix: CDN di 190+ negara |
#Single Point of Failure (SPOF)
SPOF adalah komponen yang, jika gagal, membuat seluruh sistem tidak berfungsi. Identifikasi SPOF adalah langkah pertama dalam merancang sistem reliable.
User → Load Balancer → App Server → Database
↑
SPOF: Database tunggalJika database mati, seluruh sistem down — tidak peduli berapa banyak App Server yang tersedia. Solusi: replication (database replica), failover otomatis, dan redundancy.
#CAP Theorem
CAP theorem (Brewer, 2000) menyatakan bahwa sistem terdistribusi hanya bisa memenuhi dua dari tiga sifat berikut:
| Sifat | Arti |
|---|---|
| Consistency (C) | Setiap read mendapatkan data paling terbaru dari write terakhir |
| Availability (A) | Setiap request mendapatkan response (bukan error), meskipun data mungkin stale |
| Partition Tolerance (P) | Sistem tetap beroperasi meskipun ada network partition antar node |
#Trade-off Real-World
Dalam praktik, partition tolerance wajib ada — jaringan selalu bisa terputus. Pilihan yang tersisa: CP atau AP.
| Pilihan | Karakteristik | Contoh Sistem |
|---|---|---|
| CP (Consistency + Partition) | Data konsisten, tapi availability bisa berkurang | PostgreSQL (sync replication), ZooKeeper, etcd |
| AP (Availability + Partition) | Selalu tersedia, tapi data mungkin stale | Cassandra, DynamoDB, CouchDB |
| CA (Consistency + Availability) | Tidak toleran partition — hanya untuk sistem non-distribusi | SQLite, single-node MySQL |
Note
CAP theorem sering disalahartikan sebagai "pilih dua dari tiga." Yang benar: partition tolerance wajib (karena jaringan selalu bisa gagal), jadi pilihan sebenarnya adalah consistency vs availability saat partition terjadi. Di episode 10 kita bedah ini lebih dalam dengan PACELC.
#Praktik: Identifikasi SPOF
Mari identifikasi SPOF pada sistem e-commerce sederhana:
Komponen yang sudah redundant:
- Web server (2 instance behind load balancer)
- Database replica (read可以从 replica)
Komponen yang masih SPOF:
- Load Balancer — jika mati, semua traffic gagal. Solusi: two load balancers with VRRP/floating IP.
- Database Master — jika mati, write gagal. Solusi: automatic failover ke replica (PostgreSQL Patroni, MySQL MHA).
- Redis Cache — jika mati, performa menurun tapi sistem masih jalan (graceful degradation). Bukan SPOF kritis, tapi tetap perlu redundancy.
#Penutup
Inti yang harus dibawa pulang:
- Monolith sederhana tapi punya batas scale; distributed scalable tapi kompleks.
- Tiga alasan distribusi: scale, reliability, dan geo-distribution.
- SPOF harus diidentifikasi dan dieliminasi: database, load balancer, dan komponen kritis lainnya.
- CAP theorem: partition tolerance wajib, pilih antara consistency dan availability.
Di episode 2 selanjutnya kita akan membahas scalability: horizontal vs vertical — kapan pakai mana, load balancing algorithm (round-robin, least connections), dan L4 vs L7 load balancer. Pastikan konsep CAP sudah dipahami, karena kita akan menggunakannya untuk memahami trade-off scalability!