Di kebanyakan sistem terdistribusi, beberapa node harus sepakat tentang satu nilai — siapa leader, urutan transaksi, atau isi config. Masalah ini bernama consensus, dan ia jauh lebih sulit daripada yang terlihat.

Kenapa Consensus Susah

Intuisi awam: "cukup voting mayoritas". Realitasnya: node bisa crash, pesan bisa hilang, dan network bisa terpisah sementara. Gabungan tiga hal ini membuat consensus menjadi masalah yang pernah di-prove tidak bisa diselesaikan sempurna di sistem async — dikenal sebagai FLP Impossibility (Fischer, Lynch, Paterson 1985).

Kabar baiknya: FLP tidak berarti mustahil di praktik. Dengan asumsi "biasanya sebagian besar node hidup" dan "network eventually delivers messages", algoritma seperti Raft dan Paxos memberi konsensus yang sangat reliable.

Raft — Consensus untuk Manusia

Raft sengaja dirancang agar mudah dipahami (tidak seperti Paxos). Tiga peran node:

• Leader — satu-satunya yang menerima write, mereplikasi ke follower.
• Follower — pasif, menerima replikasi dari leader.
• Candidate — sementara, saat leader mati dan pemilihan berlangsung.

Leader Election

1. Semua node mulai sebagai Follower.
2. Jika tidak terima heartbeat dari Leader dalam election timeout (150–300ms random),
   Follower menjadi Candidate, naikkan term, minta vote dari node lain.
3. Node lain memberi vote jika:
   - belum pernah vote di term ini, dan
   - log Candidate minimal sama update dengan log miliknya.
4. Kalau Candidate dapat mayoritas (quorum), ia menjadi Leader.
5. Leader kirim heartbeat reguler supaya tidak terjadi election lagi.

Timeout yang random mencegah dua node jadi Candidate barengan terus.

Log Replication

Client → Leader: "SET x = 5"
Leader append ke log lokalnya (belum committed).
Leader kirim AppendEntries ke semua Follower.
Follower tulis ke log-nya, balas ack.
Saat mayoritas (quorum) ack → Leader menandai entry "committed".
Leader balas ke client: sukses.
Follower menerima info committed di heartbeat berikutnya, lalu apply ke state machine.

Jaminannya: sekali committed, entry tidak pernah hilang — meski leader mati, leader baru pasti punya entry ini karena ia hanya dipilih jika log-nya up-to-date.

Quorum = N/2 + 1

Dengan N node, quorum adalah N/2 + 1. Artinya sistem bisa mentoleransi (N−1)/2 kegagalan.

Kenapa quorum = mayoritas, bukan semua? Karena dua quorum yang mayoritas pasti overlap minimal di satu node — node itu mencegah dua leader berbeda dipilih bersamaan. Inilah yang mencegah split-brain.

Kenapa cluster harus ganjil? Kalau 4 node terpecah 2-2, tidak ada sisi yang punya quorum → seluruh cluster berhenti menerima write. 3 atau 5 node lebih efisien.

Paxos — Induknya Semua Konsensus

Paxos (Lamport 1998) lebih umum dari Raft tapi notoriously sulit dipahami. Konsepnya mirip: ada proposer, acceptor, learner; ada dua fase (prepare, accept); perlu quorum. Varian praktis: Multi-Paxos (untuk rangkaian nilai) dan Fast Paxos.

Di industri, Raft lebih banyak dipakai karena lebih mudah diimplementasi dengan benar.

Sistem Nyata yang Pakai Consensus

• etcd (Raft) — config store untuk Kubernetes.
• Consul (Raft) — service discovery, key-value, health check.
• Zookeeper (ZAB — variant Paxos) — koordinasi Kafka, HBase, HDFS.
• CockroachDB, TiDB, Spanner (Raft / Paxos) — transaksi distributed di SQL scale.
• MongoDB replica set (mirip Raft) — leader election.

Use Case Praktis Consensus

1. Config store — "apa versi config terbaru?" Semua service harus sepakat.
2. Leader election — pilih satu node untuk tugas eksklusif (scheduler, cron runner).
3. Distributed lock — "siapa yang sekarang boleh write ke resource X?"
4. Service discovery — registry service yang konsisten antar node.
5. Ordering transaksi — Raft log = urutan operasi yang semua node pasti lihat sama.

Yang Perlu Kamu Ingat

• Consensus bukan ajaib — ia butuh quorum dan asumsi sebagian besar node hidup.
• Pakai library/sistem yang sudah teruji (etcd, Consul, Zookeeper). Jangan tulis sendiri.
• Consensus lambat relatif ke operasi lokal — tiap write butuh round-trip ke mayoritas node. Pakai hanya untuk state yang benar-benar butuh strong consistency.
• Untuk data throughput tinggi, tetap pakai eventual consistency. Consensus hanya untuk state kritis (siapa leader, config, membership).

Konsensus adalah fondasi dari hampir semua infrastruktur cloud modern — setiap kali kamu pakai Kubernetes, etcd di belakangnya sedang menjalankan Raft untukmu.

🎭 Analogi sehari-hari: Pemilihan ketua RT di kompleks. Kalau langsung tunjuk satu orang = bias. Voting mayoritas (5 dari 9 KK setuju) = ketua sah. Network putus = sebagian KK tidak bisa vote, tapi kalau >50% online dan setuju, masih sah. Itulah inti consensus.

💡 Quorum ganjil > genap: 4 node split 2-2 = deadlock, tidak ada quorum. 3 node split 2-1 = sisi 2 menang. Selalu pakai 3, 5, atau 7 node untuk consensus cluster. Genap = waste node + risk split-brain.

⚠️ Jebakan klasik:

• Tulis Paxos sendiri = bug halus, deadlock 6 bulan kemudian. Pakai etcd/Consul/ZK
• Consensus untuk high-throughput = lambat. Cuma untuk state kritis (config, leader, lock)
• Lupa jumlah node ganjil = split risk
• Treat consensus seperti DB = beda use case. Consensus = small critical state, bukan storage

🎯 Pakai consensus tools:

• Kubernetes config → etcd (built-in)
• Service discovery → Consul / etcd
• Distributed lock → Consul / Zookeeper / etcd
• Leader election → etcd dengan TTL key
• Distributed SQL → CockroachDB / TiDB (Raft di belakang)

TL;DR: Consensus = node sepakat tentang satu nilai (leader, config, urutan). Raft (dimengerti manusia) atau Paxos (lebih general). Wajib quorum N/2+1. Cluster ganjil. Lambat = cuma untuk state kritis. Pakai etcd/Consul/ZK, jangan tulis sendiri.