Belajar System Design - CAP Theorem & Consistency Models Lanjut
Memahami PACELC sebagai extension CAP, berbagai consistency models (strong, eventual, causal, read-your-writes), serta trade-off availability vs consistency saat leader down dalam sistem terdistribusi
#Pendahuluan
Setelah di episode 9 kita memahami Elasticsearch dan full-text search, pada episode ini kita kembali ke teori fundamental: CAP theorem dan consistency models. Di episode 1 kita sudah membahas CAP secara dasar; di episode ini kita bedah lebih dalam dengan PACELC dan berbagai consistency models yang menentukan perilaku sistem saat kondisi normal maupun saat kegagalan.
Pemahaman konsistensi bukan hanya teori — ia langsung mempengaruhi pilihan database, replication strategy, dan bagaimana kalian menjawab pertanyaan interview tentang trade-off. "Bagaimana jika user melihat data usang?" adalah pertanyaan yang harus bisa dijawab oleh setiap system designer.
#PACELC Theorem
PACELC adalah extension CAP yang lebih lengkap: ia menjelaskan apa yang terjadi bukan hanya saat partition, tapi juga saat kondisi normal.
IF Partition (jaringan terputus):
Choose between Availability dan Consistency (PAC)
ELSE (kondisi normal):
Choose between Latency dan Consistency (ELC)| Sistem | P(A)/E(L) | P(A)/E(C) | P(C)/E(L) | P(C)/E(C) |
|---|---|---|---|---|
| DynamoDB | Ya | |||
| Cassandra | Ya | |||
| MongoDB | Ya | |||
| PostgreSQL (sync) | Ya | |||
| Cosmos DB | Configurable | Configurable | Configurable | Configurable |
#Interpretasi PACELC
- DynamoDB: saat partition, pilih availability; saat normal, pilih latency (eventual consistency default).
- PostgreSQL (sync replication): saat partition, pilih consistency (reject writes); saat normal, pilih consistency juga (tunggu semua replica).
- Cosmos DB: bisa dikonfigurasi per query — strong consistency untuk payment, eventual untuk analytics.
#Consistency Models
#Strong Consistency
Setiap read mendapatkan data paling terbaru dari write terakhir. Tidak ada data stale.
Write(x=5) → Success
Read(x) → 5 (selalu, di semua node)Implementasi: synchronous replication, linearizability, consensus-based (Raft/Paxos). Kekurangan: write latency tinggi (tunggu semua replica), availability berkurang.
#Eventual Consistency
Jika tidak ada write baru, pada akhirnya semua node akan memiliki data yang sama. Tapi sementara waktu, node bisa memiliki data berbeda.
Write(x=5) ke Node A → Success
Read(x) di Node B → bisa 3 (lama), lalu 5 (setelah propagasi)Implementasi: asynchronous replication, Dynamo-style. Kelebihan: write latency rendah, availability tinggi. Kekurangan: data bisa stale.
#Causal Consistency
Operasi yang memiliki causal relationship (sebab-akibat) dilihat secara konsisten oleh semua node. Operasi yang tidak related bisa dilihat berbeda.
Write(x=1) → Write(y=2) [causal: y setelah x]
Read(x) di Node B → 1 (selalu, jika y=2 sudah terlihat)
Read(x) di Node C → bisa 0 (jika y=2 belum terlihat, x=1 juga belum)Contoh: chat message — "Halo" harus dilihat sebelum "Apa kabar?" di semua client. Tapi timestamp bisa berbeda antar client.
#Read-Your-Writes
Setelah user melakukan write, mereka selalu melihat data yang baru ditulis — meskipun user lain masih melihat data lama.
User A: Write(name="Budi") → Read(name) → "Budi" (selalu)
User B: Read(name) → bisa "Ani" (lama) → nanti "Budi"Implementasi: sticky session (user selalu read dari leader), atau read-after-write consistency policy.
#Monotonic Reads
Jika user melihat data versi X, mereka tidak akan pernah melihat versi yang lebih lama dari X.
User: Read → v3 → Read → v5 (atau lebih baru, tapi tidak v2)#Perbandingan Consistency Models
| Model | Guarantees | Latency | Use Case |
|---|---|---|---|
| Strong | Data selalu terbaru | Tinggi | Payment, inventory |
| Eventual | Akhirnya konsisten | Rendah | Social media feed |
| Causal | Causal order preserved | Menengah | Chat, collaborative editing |
| Read-your-writes | User lihat data sendiri | Menengah | User profile settings |
| Monotonic reads | Tidak backward | Rendah | User session |
#Praktik: Leader Down Trade-off
#Synchronous Replication (CP)
1. Leader mati
2. Follower tidak punya data terbaru (belum ter-sync)
3. Opsi: reject semua write sampai new leader terpilih (CP)
4. atau: pilih follower yang paling lengkap log-nya#Asynchronous Replication (AP)
1. Leader mati
2. Ada data yang belum ter-replikasi ke follower (data loss!)
3. Pilih follower dengan log terlengkap → jadi new leader
4. Writes diterima, tapi ada window of data loss#Recovery Strategy
Setelah failover, data yang hilang harus ditangani:
- Last-write-wins (LWW): timestamp tertentu menang — sederhana tapi bisa salah.
- Conflict resolution: merge data secara manual atau otomatis.
- Application-level: user diminta konflik data.
Warning
Dalam interview, ketika ditanya "bagaimana jika leader down?", jawaban yang baik adalah menjelaskan trade-off: sync replication mengorbankan availability untuk consistency, async mengorbankan data safety untuk availability. Tidak ada yang salah — tergantung requirement.
#Penutup
Inti yang harus dibawa pulang:
- PACELC lebih lengkap dari CAP: pilihan availability/consistency saat partition, dan latency/consistency saat normal.
- Strong consistency untuk data kritis (payment); eventual untuk performa tinggi (social feed).
- Causal consistency untuk aplikasi komunikasi (chat); read-your-writes untuk user experience.
- Leader down menunjukkan trade-off nyata: sync (CP) vs async (AP) — tidak ada jawaban benar, tergantung requirement.
Di episode 11 selanjutnya kita akan membahas distributed consensus: Raft & Paxos — bagaimana banyak node sepakat pada satu nilai untuk leader election, log replication, dan fault tolerance. Ini adalah fondasi teori yang membuat distributed system bisa bekerja dengan benar!