Studi kasus: news feed (A)

Sebelumnya, lesson 0030 menyelesaikan satu soal dalam satu lesson. News feed lebih besar, jadi dibagi dua: lesson ini mengerjakan langkah 1–4 sampai desain v1, dan lesson 0032 mengerjakan langkah 5 (deep dive fan-out). Soal ini klasik karena jawabannya bergantung hampir sepenuhnya pada angka: desain yang tepat untuk 100 ribu user salah untuk 10 juta, dan sebaliknya.

Langkah 1 — Klarifikasi requirement

• Functional: user membuat post (teks; gambar disimpan di object storage, di luar scope), follow akun lain, dan melihat home feed: post dari akun yang di-follow, urut terbaru dulu. Di luar scope: ranking dengan machine learning, iklan, komentar.
• Skala (asumsi, tanyakan): 10 juta DAU; setiap user rata-rata 1 post per hari dan membuka feed 10 kali per hari; rata-rata follow 200 akun; akun terbesar punya 10 juta follower.
• Non-functional: feed terbuka cepat (mis. p99 < 500 ms); post baru boleh muncul di feed follower beberapa detik kemudian (eventual consistency diterima); availability lebih penting daripada konsistensi kuat.

Pertanyaan "berapa follower akun terbesar?" terlihat kecil, tetapi jawabannya menentukan deep dive di lesson 0032. Tanyakan di langkah 1, jangan menunggu interviewer menyebutnya.

Langkah 2 — Estimasi

Rasio 10:1 menempatkan soal ini di keluarga read-heavy: deep dive akan berfokus pada jalur baca feed. Graf sosial di skala besar memang sangat timpang ke arah baca; paper TAO dari Facebook melaporkan bahwa "TAO can process a billion reads and millions of writes each second." ^[1] Baris terakhir tabel adalah angka yang paling penting: berapa pekerjaan database untuk satu pembukaan feed. Simpan angka itu; lesson 0032 dimulai dari sana.

Langkah 3 — API dan data model

POST /v1/posts                       { "text": "…" }   → 201 { "postId": 9001 }
POST /v1/users/77/follow                                → 204
GET  /v1/feed?limit=20&cursor=<created_at,id post terakhir>
  → 200 { "posts": [ … 20 post … ], "nextCursor": "2026-10-31T09:12:03Z,8995" }

Tabel
  posts    (id PK, author_id, text, created_at)
           INDEX (author_id, created_at DESC)
  follows  (follower_id, followee_id, created_at, PK (follower_id, followee_id))
           INDEX (followee_id)                       ← daftar follower, dipakai di lesson 0032

Kenapa cursor, bukan OFFSET. Dokumentasi PostgreSQL: "The rows skipped by an OFFSET clause still have to be computed inside the server; therefore a large OFFSET might be inefficient." ^[2] Feed juga terus bertambah di atas: dengan OFFSET 20, satu post baru menggeser semua halaman sehingga user melihat post yang sama dua kali. Cursor menyimpan posisi post terakhir (created_at, lalu id sebagai pemutus seri) dan halaman berikutnya mulai tepat dari sana.

Kenapa index (author_id, created_at). "A multicolumn B-tree index can be used with query conditions that involve any subset of the index's columns, but the index is most efficient when there are constraints on the leading (leftmost) columns." ^[3] Query feed selalu menyaring author_id, lalu mengurutkan menurut waktu, jadi urutan kolom itu cocok dengan bentuk query.

Langkah 4 — High-level design (v1)

Desain v1 paling sederhana: fan-out on read. Saat post dibuat, hanya satu baris yang ditulis ke posts. Feed dirakit saat dibaca:

SELECT p.* FROM posts p
JOIN follows f ON f.followee_id = p.author_id
WHERE f.follower_id = :me
  AND (p.created_at, p.id) < (:cursor_time, :cursor_id)
ORDER BY p.created_at DESC, p.id DESC
LIMIT 20;

App server stateless di belakang load balancer, satu PostgreSQL. Tidak ada cache, queue, atau worker. Saat peluncuran (mis. 100 ribu DAU) puncak feed hanya ±30 QPS, atau ±6.000 pencarian index per detik. Itu wajar untuk dicoba di satu database; ukur dengan EXPLAIN ANALYZE sebelum menambah komponen apa pun. Desain ini juga benar secara otomatis: post yang dihapus atau akun yang di-unfollow langsung hilang dari feed, karena feed tidak pernah disalin.

Di mana v1 berhenti cukup. Di skala target, pekerjaan baca menjadi ±600.000 pencarian index per detik pada puncak, dan setiap pembukaan feed menggabungkan dan mengurutkan post dari 200 penulis. Read replica bisa membagi beban itu, tetapi tidak mengurangi pekerjaan per feed. Pertanyaannya: bisakah feed disiapkan sebelum dibaca?

Desain v1 sudah berdiri, dan angka 600.000 sudah di tangan. Lanjut di lesson 0032: langkah 5, fan-out on write vs on read, dan hybrid untuk akun besar.

Istilah: GLOSSARY.md (bagian "Studi kasus") · Indeks: semua lesson System Design

Ada yang belum jelas? Tanyakan ke saya (agent) di terminal, misalnya: "kenapa cursor memakai id sebagai pemutus seri?", "kapan read replica cukup untuk feed?", atau "bagaimana feed berubah kalau ada ranking?"

Sumber: [1] Bronson et al., TAO: Facebook's Distributed Data Store for the Social Graph (USENIX ATC 2013) · [2] PostgreSQL docs: LIMIT and OFFSET · [3] PostgreSQL docs: Multicolumn Indexes