Mock interview 45 menit: typeahead (autocomplete)

• Functional: setiap kali user mengetik, tampilkan maksimal 10 saran yang diawali teks yang sudah diketik (prefix), diurutkan berdasarkan popularitas pencarian. Di luar scope: koreksi salah ketik, saran personal per user, banyak bahasa.
• Skala (asumsi, disetujui interviewer): 10 juta DAU, 10 pencarian per user per hari, ±10 juta term unik.
• Latency: p99 di bawah 100 ms, karena saran harus muncul saat user masih mengetik.
• Consistency: urutan popularitas boleh telat ±1 jam. Term yang baru viral tidak harus langsung muncul.
• Availability: 99,9%. Kalau typeahead mati, pencarian biasa tetap berjalan, jadi fitur ini boleh degradasi (kotak pencarian tanpa saran).

Kalimat kunci: "boleh telat satu jam" dan "boleh degradasi". Keduanya akan membuat desain jauh lebih murah di langkah 4 dan 5.

Kesimpulan angka: sangat read-heavy (±4 baca per pencarian, tulis hanya ke log), data kecil, dan target latency ketat. Deep dive nanti berfokus pada jalur baca, bukan storage.

GET /suggest?q=ind&limit=10
  → 200 OK   { "suggestions": ["indonesia", "indomaret", "indihome", …] }

Log pencarian (append-only, dari layanan search yang sudah ada)
  term, searched_at

Tabel term_counts            ← dihitung ulang batch job setiap jam dari log
  term   text    PRIMARY KEY
  count  bigint
  index: (term text_pattern_ops)   ← untuk LIKE 'prefix%'

Kenapa text_pattern_ops: dokumentasi PostgreSQL menyebut operator class ini membandingkan nilai "strictly character by character", sehingga cocok untuk "queries involving pattern matching expressions (LIKE or POSIX regular expressions)" kalau database tidak memakai locale "C". ^[1]

v1: satu app server stateless dan satu PostgreSQL. Baca: SELECT term FROM term_counts WHERE term LIKE 'ind%' ORDER BY count DESC LIMIT 10. Tulis tidak lewat request saran sama sekali: batch job setiap jam membaca log pencarian, menghitung ulang term_counts, lalu menggantinya. Karena popularitas boleh telat satu jam, tidak ada counter yang ditulis setiap ketikan.

Kalimat untuk interviewer: "Untuk mulai cukup satu app server dan PostgreSQL dengan index prefix. Kalau p99 melewati 100 ms, saya ukur query-nya dulu, lalu mulai dari perubahan termurah."

Evolusi dari v1 ke v2, satu komponen per alasan:

1. Ukur dulu. EXPLAIN ANALYZE menjalankan query dan menampilkan waktu sebenarnya per node rencana. ^[2] Hasil yang diharapkan: prefix panjang ("indom") cepat, prefix pendek ("a", "in") lambat, karena index memang menemukan barisnya tapi ORDER BY count harus menimbang ratusan ribu baris yang cocok.
2. p99 prefix pendek > 100 ms: precompute. Batch job yang sama menulis tabel prefix_topk(prefix PRIMARY KEY, suggestions) berisi 10 saran teratas untuk setiap prefix 1–10 karakter (±6 GB). Baca menjadi satu lookup primary key. Ini trie (prefix tree) yang "diratakan" menjadi tabel; trie di memori adalah alternatif yang sama cepatnya tapi harus dibangun ulang dan direplikasi sendiri. Biayanya: batch job lebih lama, dan saran tetap telat sampai satu jam, yang sudah diizinkan requirement.
3. 8.000 QPS puncak: saran untuk satu prefix hanya berubah setiap jam, jadi respons boleh di-cache. RFC 9111: directive max-age menyatakan respons "is to be considered stale after its age is greater than the specified number of seconds". ^[3] Cache-Control: public, max-age=3600 membuat browser dan CDN menyerap prefix populer. Biayanya: saran bisa basi sampai satu jam lebih, dan CDN adalah biaya bulanan.
4. Availability 99,9%: server kedua di belakang load balancer. Server stateless, jadi tidak ada state yang dipindah.
5. Kalau database masih jenuh setelah cache: salin prefix_topk (±6 GB) ke Redis sebagai key-value. Sorted set Redis bisa mencari rentang leksikografis kalau semua anggotanya memakai score yang sama ^[4], tapi hasilnya diurutkan menurut abjad, bukan popularitas; karena itu key per prefix berisi daftar top-10 lebih cocok.
6. Yang tidak ditambahkan: sharding (6 GB muat di satu node), Kafka + stream processing (popularitas boleh telat satu jam), microservices (satu tim, satu fitur). SRE Book menyebut kompleksitas seperti ini accidental complexity, yang "can be resolved with engineering effort", berbeda dengan kompleksitas yang melekat pada masalahnya. ^[5] Sebut sinyal kapan naik: kalau requirement berubah menjadi "trending dalam 1 menit", baru stream processing dibenarkan.