Pernah mikir gak, pas kamu ketik “Burger” di Uber Eats, kenapa hasilnya beda sama temanmu? Dan kenapa resto yang “Tutup” jarang muncul?
Uber Engineering baru aja sharing evolusi gila-gilaan dari sistem pencarian pengiriman (Delivery Search) mereka. Ini bukan sekadar SELECT * FROM restaurants lho!
1. ⚠️ Problem Statement (Masalah)
* Kompleksitas Ganda: Pencarian harus menggabungkan Geospatial (lokasi), Text (nama makanan), dan Availability (buka/tutup) secara bersamaan.
* The “Hangry” Factor: User yang lapar tidak punya kesabaran. Latensi harus super rendah (sub-second).
* Real-time Inventory: Stok makanan dan status resto berubah tiap detik. Search engine standar sering menampilkan data basi (resto tutup tapi dibilang buka).
2. 🛠️ Metodologi & Solusi
Uber memisahkan sistem menjadi dua fase utama (Classic Search Architecture):
* Phase 1: Retrieval (Recall): Menggunakan Apache Lucene/Elasticsearch untuk menyaring ribuan restoran di sekitarmu menjadi ratusan kandidat relevan (berdasarkan lokasi & keyword).
* Phase 2: Ranking (Precision): Ratusan kandidat tadi diurutkan ulang pakai Machine Learning (Learning to Rank). Model ini memprediksi: “Seberapa besar kemungkinan user ini beli makanan ini?”.
* Hailstorm (Indexer): Mereka membangun sistem indexing kustom yang bisa mengupdate status restoran di search index dalam hitungan detik via Kafka.
3. 📈 Findings & Hasil
* ⚡ Personalized Experience: Hasil pencarian benar-benar disesuaikan dengan selera user (berdasarkan history order), bukan cuma relevansi teks.
* ✅ High Accuracy: Komplain user soal “pesan tapi ternyata resto tutup” berkurang drastis berkat real-time updates.
* 🚀 Scalability: Sistem ini mampu menangani jutaan Queries Per Second (QPS) secara global dengan latensi rendah.
4. 💡 Key Takeaways
* Search != Database: Jangan pakai database transaksional (SQL) buat fitur search yang kompleks. Pisahkan!
* Recall vs Precision: Jangan coba melakukan ranking berat di fase awal. Filter dulu (Recall), baru urutkan dengan ML (Precision).
* Freshness is King: Di bisnis O2O (Online to Offline), data yang real-time lebih penting daripada algoritma yang canggih tapi lambat.
💻 How to Use / Implementation (Architectural Pattern)
Kamu tidak bisa “install” Uber Search karena ini proprietary, tapi kamu bisa meniru arsitekturnya untuk aplikasi e-commerce/delivery kamu:
* The Base (Retrieval Layer):
Gunakan Elasticsearch atau Opensearch.
* Simpan dokumen restoran dengan Geo-point.
* Lakukan query standar (Geo Distance + Text Match) untuk mengambil top-500 kandidat.
* The Brain (Ranking Layer):
Gunakan XGBoost atau TensorFlow Ranking.
* Ambil 500 kandidat dari langkah 1.
* Kirim ke model ML (Ranking Service) yang menilai skor berdasarkan fitur user (misal: user suka pedas).
* Urutkan ulang (Re-rank) sebelum dikirim ke HP user.
* Real-time Updates:
Gunakan Apache Kafka + CDC (Change Data Capture).
* Jika resto ubah status di DB utama -> Kafka -> Update dokumen di Elasticsearch secara partial update.
🔗 Baca Blog Engineering Lengkapnya:
https://www.uber.com/en-NL/blog/evolution-and-scale-of-ubers-delivery-search-platform/
#UberEngineering #SystemDesign #SearchEngine #Elasticsearch #MachineLearning #Microservices #TechArchitecture #RealTimeData
