Buat feed

Pertanyaan

Kapan feed dibangun saat posting, kapan saat dibaca, dan bagaimana klien mengejar yang terlewat?

Setelah baca ini, kamu bisa membandingkan fan-out saat tulis, saat baca, dan hibrida dengan angka, menangani akun dengan pengikut timpang, dan merancang pemulihan feed yang tidak bergantung pada pengiriman real-time.

Prasyarat dan contoh

Kamu sudah paham graf pengikut (M13.04), cache (M06), dan antrean untuk kerja asinkron (M10).

Platform dengan 10 juta pengguna harian. Tiap pengguna membuka feed 10 kali sehari dan mengikuti rata-rata 200 akun. Pembacaan jauh lebih sering dari penulisan: 100 juta pembukaan feed per hari (sekitar 1.150 per detik rata-rata, mungkin 5.000 di puncak) lawan misalnya 5 juta posting per hari (sekitar 58 per detik). Rasio itu yang menentukan di mana kerja sebaiknya dilakukan.

Mekanisme

Pull (fan-out saat baca). Saat feed dibuka, ambil daftar akun yang diikuti, ambil posting terbaru tiap akun, gabungkan dan urutkan. Penulisan murah: satu insert. Pembacaan mahal: 200 akun berarti 200 pencarian atau satu query besar, di tiap pembukaan. Di 5.000 pembukaan per detik, itu sekitar 1 juta pencarian per detik di puncak.

Push (fan-out saat tulis). Saat posting, tulis ID posting ke timeline tiap pengikut, misalnya daftar terbatas 800 ID per pengguna di cache atau penyimpanan cepat. Pembacaan murah: ambil satu daftar, lalu hydrate ID jadi isi posting. Penulisan mahal: akun dengan 200 pengikut = 200 tulis, wajar. Akun dengan 20 juta pengikut = 20 juta tulis per posting. Di 100.000 tulis per detik, itu 200 detik untuk satu posting, dan antrean fan-out tertahan di belakangnya.

Hibrida. Pakai push untuk akun biasa, pull untuk akun besar. Tentukan ambang, misalnya 100.000 pengikut. Saat feed dibuka: ambil timeline yang sudah di-push, ambil posting terbaru dari akun besar yang diikuti (biasanya hanya beberapa), lalu gabungkan. Pembacaan tetap murah, dan tidak ada fan-out 20 juta. Tambahan: jangan push ke pengguna yang tidak aktif 30 hari. Saat mereka kembali, bangun timeline-nya dengan pull sekali.

Timeline sebagai cache. Daftar yang di-push itu salinan turunan, bukan sumber kebenaran. Sumber kebenarannya posting dan graf pengikut. Konsekuensinya timeline boleh hilang dan dibangun ulang, dan posting yang dihapus harus disaring saat hydrate, karena menghapusnya dari jutaan timeline nggak praktis.

Event yang terlewat. Pengiriman real-time ("ada posting baru") hanya petunjuk. Klien menyimpan kursor (ID atau waktu posting terbaru yang sudah dilihat). Saat nyambung ulang atau membuka feed, ia minta "semua setelah kursor". Server mengembalikan halaman berbatas, dan klien mengulang sampai habis. Kalau jaraknya terlalu jauh (misalnya lebih dari 800 item), server menjawab "reset": klien mengganti seluruh feed alih-alih menjahit celah panjang.

Follow baru. Orang yang baru difollow belum ada di timeline. Backfill: saat follow, salin sekitar 20 posting terakhir akun itu ke timeline, atau saat membaca gabungkan lewat pull. Unfollow disaring saat baca.

Saat rancangan ini gagal

• Push murni untuk akun besar. Satu posting selebritas membanjiri antrean fan-out, dan posting akun biasa tertunda belasan menit.
• Pull murni dengan banyak followee. Latensi buka feed naik seiring jumlah akun yang diikuti, dan database baca kena beban besar.
• Timeline dianggap kebenaran. Cache hilang, feed kosong, dan tak ada jalur membangun ulang.
• Posting dihapus tetap muncul. Timeline menyimpan ID tapi hydrate tidak memeriksa status hapus atau privasi.
• Celah tanpa kursor. Klien terputus 10 menit, real-time tidak diulang, dan feed melewatkan posting tanpa ada yang tahu.
• Buffer replay tak terbatas. Menyimpan semua event untuk setiap klien yang pernah putus membuat memori tumbuh tanpa batas. Batasi dan sediakan jalur "reset".

Contoh tandingan: komunitas dengan 5.000 pengguna dan rata-rata 30 akun diikuti cukup pull murni. Satu query dengan indeks sudah cepat, dan push hanya menambah komponen yang harus dirawat.

Latihan

Sistem punya 2 juta pengguna harian, posting 1 juta per hari, rata-rata 150 pengikut. Satu akun punya 5 juta pengikut dan posting 4 kali sehari. Antrean fan-out mampu 50.000 tulis per detik.

1. Berapa tulis per hari untuk push murni (rata-rata biasa), dan berapa untuk satu posting akun besar?
2. Berapa lama satu posting akun besar menghabiskan antrean?
3. Rancang hibrida dan sebut apa yang dilakukan saat feed dibuka.
4. Klien terputus 5 menit. Bagaimana ia mengejar?

Lihat pembahasan+

1. Push murni: 1 juta × 150 = 150 juta tulis per hari (sekitar 1.700 per detik rata-rata). Satu posting akun besar: 5 juta tulis.
2. 5 juta ÷ 50.000 = 100 detik, dan 4 posting per hari memonopoli antrean 400 detik. Selama itu posting akun lain antre di belakangnya.
3. Ambang di sekitar 100.000 pengikut. Akun biasa di-push. Akun besar tidak: posting disimpan sekali. Saat feed dibuka: ambil timeline push, ambil posting terbaru akun besar yang diikuti lewat pull, gabungkan menurut waktu, saring yang dihapus, lalu hydrate.
4. Klien mengirim kursor terakhir. Server mengembalikan posting setelah kursor, per halaman. Kalau jaraknya melebihi batas timeline (800 item), server mengirim "reset" dan klien memuat ulang dari awal. Tidak ada replay tanpa batas.

Terkait

• Sebelumnya: M13.04 Representasikan graf sosial.
• Kursor sinkronisasi dibahas dari sisi chat di M13.03 Kirim pesan chat.
• Lanjut ke M13.06 Berkolaborasi secara konkuren.
• Cache dari M06 dan antrean dari M10 dipakai di sini. Rancangan D15 belum tersedia.

Catatan

• Asumsi: urutan feed kronologis, bukan peringkat hasil model.
• Angka ambang, ukuran timeline, dan kapasitas antrean hanyalah contoh hitungan.
• Yang nggak dibahas: peringkat feed, iklan, moderasi, dan notifikasi push OS.
• Pola push, pull, dan hibrida adalah praktik umum, bukan klaim tentang platform tertentu.
• Terakhir ditinjau: 26 Oktober 2026.