Index dulu, baru replica: B-tree, leader-follower, replication lag
Dua anak tangga termurah untuk database yang mulai lambat: index yang tepat, lalu read replica untuk beban baca
Sebelumnya, lesson 0008 menetapkan database relasional sebagai default. Database itu lama-lama melambat. Jawaban yang dicari interviewer bukan "ganti database" atau "langsung sharding", tapi urutan yang termurah dulu: ukur query-nya, tambah index, baru tambah salinan database untuk membaca.
EXPLAIN dan index B-tree dulu, lalu leader-follower dengan read replica,
beda synchronous vs asynchronous replication, dan cara menangani replication lag.
1. Index: ukur dengan EXPLAIN, perbaiki dengan B-tree
Tanpa index, query WHERE id = … memaksa database "scan the entire test1 table, row by row, to find all matching entries."
Index membuat database bisa menemukan baris jauh lebih cepat, dan setelah dibuat, "the system will update the index when the table is modified". Harganya: "This adds overhead to data manipulation operations." [1]
Jenis default-nya B-tree: "By default, the CREATE INDEX command creates B-tree indexes, which fit the most common situations."
B-tree menangani "equality and range queries on data that can be sorted into some ordering", yaitu operator < <= = >= >, plus BETWEEN dan IN. [2]
B-tree adalah pohon terurut yang seimbang: mencari satu nilai di jutaan baris hanya menelusuri beberapa level pohon, bukan semua baris.
Ukur sebelum menambah index. EXPLAIN menunjukkan "what query plan the planner creates for any query" (mis. Seq Scan = baca seluruh tabel), dan EXPLAIN ANALYZE "actually executes the query, and then displays the true row counts and true run time". [3]
EXPLAIN ANALYZE: Seq Scan?→
index B-tree di kolom WHERE / ORDER BY→
ukur ulang
Satu index yang tepat sering mengubah query dari ratusan milidetik ke beberapa milidetik, tanpa server baru. Index terlalu banyak memperlambat setiap INSERT/UPDATE, jadi index hanya untuk query yang memang sering.
Latihan 1 — Index
Jawab tanpa scroll ke atas. Soal yang sama akan muncul lagi, diacak, di review 0019.
Kuis di lesson ini adalah feedback cepat, bukan bukti penguasaan; yang dicatat hanya hasil review 0019.
2. Leader-follower replication dan read replica
Kalau query sudah ber-index dan beban baca tetap terlalu besar untuk satu server, salin database ke server lain. Pola umumnya leader-follower (PostgreSQL menyebutnya primary-standby): semua write ke leader, leader mengirim perubahan (WAL, log perubahan) ke satu atau lebih follower. Follower yang melayani query baca disebut read replica; di PostgreSQL namanya hot standby, yaitu kemampuan "to connect to the server and run read-only queries while the server is in archive recovery or standby mode." Koneksinya "strictly read-only". [4]
Synchronous vs asynchronous
| Asynchronous (default PostgreSQL) | Synchronous | |
|---|---|---|
| Commit selesai saat… | WAL tercatat di leader | leader dan standby sinkron sudah konfirmasi |
| Latency write | rendah | naik (menunggu jaringan + disk standby) |
| Leader crash | transaksi terakhir bisa hilang | tidak hilang (2-safe) |
Dokumentasi PostgreSQL: "Streaming replication is asynchronous by default", sehingga "there is a small delay between committing a transaction in the primary and the changes becoming visible in the standby."
Konsekuensinya: "If the primary server crashes then some transactions that were committed may not have been replicated to the standby server, causing data loss." [5]
Dengan synchronous replication, "each commit of a write transaction will wait until confirmation is received that the commit has been written to the write-ahead log on disk of both the primary and standby server", dan pemakaian yang tidak hati-hati "will reduce performance for database applications because of increased response times and higher contention." Lag bisa dipantau lewat view pg_stat_replication. [5]
Replication lag dan read-your-writes
Replication lag adalah jeda itu: user mengubah profil (write ke leader), halaman reload membaca dari replica yang belum menerima perubahannya, dan user melihat data lama. Penanganan yang biasa disebut di interview:
- baca dari leader untuk data milik user sendiri sesaat setelah ia menulis (mis. selama beberapa detik setelah write), replica untuk data orang lain;
- pantau lag dan keluarkan replica dari pool baca kalau lag melewati batas;
- query yang wajib akurat (saldo, stok saat checkout) selalu ke leader.
Jaminan "selalu melihat tulisan sendiri" ini disebut read-your-writes; model konsistensinya dibahas di lesson 0011.
Latihan 2 — Replication
Jawab tanpa scroll ke atas.
3. Kapan tidak perlu
- Sinyal yang membenarkan read replica. Query sudah diukur dengan
EXPLAIN ANALYZEdan ber-index, scale vertical sudah dicoba, dan CPU/IO database tetap jenuh oleh read (rasio baca:tulis tinggi, mis. 10:1 atau lebih). Juga: butuh standby untuk failover, yang memang alasan ketersediaan, bukan performa. - Biaya dan risiko. Server dan biaya kedua, routing baca/tulis di aplikasi, dan bug replication lag (user melihat data lama). Synchronous replication menambah latency setiap write. Replica tidak membantu sama sekali kalau bottleneck-nya write.
- Alternatif lebih murah. Index yang tepat, memperbaiki query (N+1,
SELECT *), scale vertical, lalu cache untuk data panas (modul Caching). Untuk 1.000 user aktif harian, satu database dengan index yang benar sudah cukup.
Kalimat untuk interview: "Untuk skala ini satu PostgreSQL dengan index di kolom yang di-query cukup. Kalau CPU database di atas 70% karena read setelah index dan scale vertical, saya tambah read replica asinkron dan membaca data milik user sendiri dari leader."
Latihan lisan — Ucapkan dengan suara keras
Pasang timer dan jawab dengan suara keras, seolah sedang interview. Jangan buka jawaban contoh sebelum selesai.
"Database Anda kewalahan oleh query baca. Apa yang Anda lakukan, berurutan, dan apa trade-off-nya?" (60 detik)
Bandingkan dengan jawaban contoh dan checklist-nya
"Pertama ukur: lihat query paling lambat dan paling sering, jalankan EXPLAIN ANALYZE. Kalau ada Seq Scan di tabel besar, tambah index B-tree di kolom filter atau sort; itu sering cukup, dan harganya hanya write sedikit lebih lambat. Kalau sudah ber-index, sudah scale vertical, dan CPU database masih jenuh oleh read, saya tambah read replica: write tetap ke leader, read ke follower. Replikasinya asinkron, default PostgreSQL, supaya write tidak menunggu; konsekuensinya replication lag dan kemungkinan kehilangan transaksi terakhir kalau leader crash. Synchronous menghindari itu tapi menambah latency setiap commit. Untuk lag, data milik user sendiri sesaat setelah ia menulis dibaca dari leader (read-your-writes), dan replica yang lag-nya terlalu besar dikeluarkan dari pool."
Checklist: apakah Anda menyebut…
- ukur dulu (EXPLAIN / query paling lambat) sebelum menambah komponen?
- index B-tree di kolom filter/sort, dengan biaya write lebih lambat?
- leader-follower: write ke leader, read ke read replica?
- async vs sync: async = latency rendah tapi lag dan risiko kehilangan data; sync = aman tapi write lebih lambat?
- penanganan replication lag (baca dari leader setelah write, pantau lag)?
- membenarkan replica dengan angka atau metrik (mis. CPU database jenuh oleh read setelah index)?
Lulus jika minimal 4 dari 6.
Berikutnya, lesson 0010: kalau yang jenuh adalah write atau ukuran data, replica tidak menolong. Saatnya partitioning dan consistent hashing.
Istilah: GLOSSARY.md (bagian "Data") · Indeks: semua lesson System Design
Ada yang belum jelas? Tanyakan ke saya (agent) di terminal, misalnya: "bagaimana membaca output EXPLAIN ANALYZE baris per baris?", "kapan composite index (a, b) dipakai untuk query WHERE b = …?", atau "bagaimana failover ke standby berjalan kalau leader mati?"
Sumber: [1] PostgreSQL docs: Indexes, Introduction · [2] PostgreSQL docs: Index Types · [3] PostgreSQL docs: Using EXPLAIN · [4] PostgreSQL docs: Hot Standby · [5] PostgreSQL docs: Log-Shipping Standby Servers (streaming dan synchronous replication)