Pernah penasaran gimana LinkedIn mengatur miliaran update di Feed kita tanpa lemot? Ternyata, rahasianya ada di FishDB, sebuah generic retrieval engine yang mereka bangun sendiri.
Mari kita bedah ringkasannya! 👇
🛑 1. The Problem (Masalah Utama)
Dulu, infrastruktur feed LinkedIn (“Timelines”) sangat spesifik dan kaku. Setiap kali ada fitur baru (misal: video ads, viral conversation), engineer harus menulis kode backend kustom yang rumit.
* Isu: Development cycle jadi lambat, maintenance berat, dan sulit untuk melakukan scaling seiring bertambahnya jenis konten.
💡 2. Solusi & Metodologi: FishDB
LinkedIn membangun FishDB, sebuah mesin pencari data (retrieval engine) yang bersifat generik.
* Hipotesis: Daripada bikin storage khusus untuk tiap fitur, lebih baik buat satu platform yang bisa dikonfigurasi.
* Tech Stack: Dibangun di atas RocksDB (sebagai storage engine yang cepat) dan Kafka (untuk replikasi data).
* Konsep: Memisahkan logic bisnis dari logic penyimpanan. Engineer cukup mendefinisikan “skema” data mereka, dan FishDB yang mengurus cara menyimpannya.
📈 3. Impact & Result
Sejak migrasi ke FishDB, hasilnya signifikan:
* Kecepatan Iterasi: Engineer bisa meluncurkan fitur feed baru dalam hitungan hari, bukan bulan.
* Skalabilitas: Mampu menangani read/write traffic yang sangat masif dengan latency rendah.
* Efisiensi: Mengurangi beban operasional karena semua feed menggunakan infrastruktur yang sama.
⚙️ 4. How It Works (Konsep Teknis)
FishDB bekerja dengan model Primary Key dan Secondary Index.
* Write: Data masuk dari Kafka 👉 FishDB memproses dan menyimpannya di RocksDB local store.
* Read: Client melakukan query (misal: “Ambil semua post user X dalam 24 jam terakhir”). FishDB menerjemahkan query ini menjadi scan yang efisien di RocksDB.
* Replikasi: Menggunakan Leader-Follower model untuk menjamin data tidak hilang.
📝 5. Key Takeaways
* Abstraction is Power: Jangan membebani developer aplikasi dengan kerumitan storage. Buat layer abstraksi.
* Don’t Reinvent the Wheel: LinkedIn menggunakan teknologi yang sudah matang (RocksDB & Kafka) sebagai fondasi, lalu membangun logic di atasnya.
* Generic > Specific: Untuk sistem berskala besar, solusi yang generik (bisa dipakai banyak kasus) jauh lebih maintainable daripada solusi “tambal sulam”.
Gimana menurut kalian? Apakah pendekatan generic engine ini bisa diterapkan di sistem kalian? Diskusi di kolom komentar ya! 👇
🔗 Sumber Lengkap:
https://www.linkedin.com/blog/engineering/infrastructure/fishdb-a-generic-retrieval-engine-for-scaling-linkedins-feed
#SoftwareEngineering #SystemDesign #LinkedIn #Scalability #RocksDB #BackendEngineering #TechNews #FishDB