Belajar System Design - Replication Strategies Lanjut

#Pendahuluan

Setelah di episode 11 kita memahami distributed consensus (Raft & Paxos), pada episode ini kita bedah replication strategies secara lebih detail. Replication adalah bagaimana data diduplikasi ke beberapa node — dan ada banyak cara melakukannya, masing-masing dengan trade-off yang berbeda.

Di dunia nyata, pilihan replication strategy mempengaruhi latency, availability, dan data safety. Tidak ada satu ukuran untuk semua — kalian harus memahami trade-off untuk memilih yang tepat sesuai kebutuhan sistem.

#Leader-Follower Replication

#Async vs Semi-Sync vs Sync

Metode	Write Latency	Read Latency	Data Loss Risk	Availability
Async	Rendah	Rendah	Window of loss	Tinggi
Semi-sync	Menengah	Rendah	Minimal (1 replica)	Menengah
Sync	Tinggi	Rendah	Nol (semua replica)	Rendah

#Async Replication

Async replication flow

1. Client write ke Leader
2. Leader simpan ke local disk → return success ke client (cepat!)
3. Leader async propagate ke Follower
4. Jika Leader mati sebelum step 3 → DATA LOSS pada follower

Digunakan di: MySQL default, PostgreSQL async standby, DynamoDB (default).

#Semi-Sync Replication

Semi-sync replication flow

1. Client write ke Leader
2. Leader propagate ke minimal 1 Follower
3. Follower acknowledge (data sudah ada di 2 node)
4. Leader return success ke client

Digunakan di: MySQL semi-sync, PostgreSQL synchronous_standby_names (satu standby).

#Sync Replication

Sync replication flow

1. Client write ke Leader
2. Leader propagate ke SEMUA Follower
3. Semua Follower acknowledge
4. Leader return success ke client

Digunakan di: Google Spanner, CockroachDB (serializable), financial systems.

#Automatic Failover

Saat leader mati, sistem harus otomatis memilih leader baru:

Tool	Metode	Digunakan di
PostgreSQL Patroni	Raft-based leader election	Production PostgreSQL
MySQL MHA	Semi-automatic failover	MySQL replication
Redis Sentinel	Monitor + failover	Redis cluster
HashiCorp Consul	Service discovery + health check	Infrastructure

Failover process (Patroni)

1. Patroni detect leader down (health check timeout)
2. Semua Patroni nodes election → pilih new leader
3. New leader promote dari replica (menjadi writable)
4. Replicas point ke new leader
5. Old leader (jika recover) menjadi follower

#Multi-Leader Replication

#Active-Active

Beberapa node bisa menerima write secara bersamaan — biasanya di deployment multi-datacenter.

Multi-leader setup

DC-US: Leader A (write)
DC-EU: Leader B (write)
DC-Asia: Leader C (write)
 
A ↔ B: async replication
B ↔ C: async replication
A ↔ C: async replication

Kapan pakai: aplikasi global yang membutuhkan write low-latency di semua region.

#Conflict Resolution

Ketika dua leaders menulis ke data yang sama secara bersamaan → conflict.

Strategy	Penjelasan	Kapan Pakai
Last-write-wins (LWW)	Timestamp tertentu menang	Simple, tolerable data loss
CRDT	Conflict-free replicated data type — merge otomatis	Counter, set, register
Application-level	Logik bisnis menentukan mana yang menang	Complex business rules
Manual merge	User pilih versi mana yang benar	Collaborative editing

#CRDT (Conflict-free Replicated Data Type)

CRDT types

- G-Counter: grow-only counter (distributed counter)
- PN-Counter: positive-negative counter (bisa increment & decrement)
- G-Set: grow-only set (tambah tapi tidak hapus)
- OR-Set: observed-remove set (tambah & hapus, conflict-free)

CRDT menjamin state convergence tanpa koordinasi — cocok untuk collaborative apps (Google Docs, Figma).

#Leaderless Replication (Dynamo-Style)

#Quorum Read/Write

Quorum R + W > N

N = 3 (total replicas)
W = 2 (write quorum: tulis ke minimal 2 replica)
R = 2 (read quorum: baca dari minimal 2 replica)
 
R + W = 4 > N = 3 → guarantee strong consistency!

Jika R + W > N, ada overlap antara write dan read → data yang di-read pasti yang terbaru.

#Quorum Tuning

Setting	Karakteristik	Use Case
W=N, R=1	Write lambat, read cepat	Read-heavy (analytics)
W=1, R=N	Write cepat, read lambat	Write-heavy (logging)
W=1, R=1	Sangat cepat, no guarantee	Metrics, non-critical
W=ceil(N/2+1), R=ceil(N/2+1)	Balanced	General purpose

#Anti-Entropy Repair (Merkle Tree)

Merkle tree repair

Replica A: hash(TREE)
Replica B: hash(TREE)
 
Jika hash berbeda → compare subtree → compare subtree → sampai data yang berbeda ditemukan
→ sync data yang berbeda saja

Merkle tree memungkinkan deteksi perbedaan data secara efisien tanpa membandingkan seluruh dataset. Digunakan di Cassandra, DynamoDB.

Note

Untuk interview, kuasai trade-off leader-leader vs leaderless. Leader-based mudah dipahami tapi punya bottleneck di leader; leaderless scalable tapi butuh quorum dan anti-entropy. Pilihan tergantung: apakah kalian butuh strong consistency atau availability tinggi?

#Praktik: Aplikasi Global

Desain replication untuk global app

User di US → write ke DC-US (low latency)
User di Asia → read dari DC-Asia (low latency)
Sync: DC-US async replicate ke DC-Asia (delay 100-200ms)
 
Conflict: jika user US dan Asia write data yang sama
→ LWW berdasarkan NTP-synchronized timestamp
→ atau CRDT untuk data yang bisa di-merge otomatis

#Penutup

Inti yang harus dibawa pulang:

Async: write cepat, risk data loss; semi-sync: balance; sync: aman tapi lambat.
Failover otomatis (Patroni, Sentinel, Consul) wajib untuk production — jangan manual failover.
Multi-leader untuk global write low-latency; conflict resolution (LWW, CRDT, application-level) harus dipilih sesuai data type.
Leaderless (Dynamo-style) dengan quorum R + W > N untuk availability tinggi; Merkle tree untuk anti-entropy repair.

Di episode 13 selanjutnya kita akan membahas sharding & partitioning — hash-based vs range-based vs directory-based, resharding online, cross-shard queries, dan desain sharding untuk social media timeline. Sharding adalah kunci untuk horizontal scale database di skala ratusan juta row!