Design Uber

Prompt latihan

1. Problem Statement, Functional Requirements, and Scale Assumptions

   Tentukan ruang lingkup platform ride-hailing: penumpang meminta perjalanan dengan menentukan lokasi jemput dan tujuan, sistem mencocokkan penumpang dengan pengemudi terdekat yang tersedia, pengemudi menerima perjalanan, kedua pihak melacak lokasi satu sama lain secara real-time selama perjalanan, dan tarif dihitung serta ditagih di akhir. Kecualikan secara eksplisit pengiriman makanan (Uber Eats), perjalanan terjadwal, carpooling (UberPool), widget estimasi tarif, dan onboarding/background check pengemudi dari desain awal. Nyatakan asumsi skala awal (perjalanan harian, pengemudi aktif per kota, frekuensi update lokasi, target latensi match) sebelum mengusulkan komponen apa pun.

2. Non-Functional Requirements

   Tentukan NFR utama: latensi match (penumpang harus menerima match pengemudi dalam 5-10 detik dari permintaan), frekuensi update lokasi (pengemudi mengirim lokasi setiap 4-5 detik selama perjalanan aktif), konsistensi lokasi real-time (tampilan penumpang dan pengemudi harus dalam 10 detik dari posisi aktual satu sama lain), konsistensi state perjalanan (state perjalanan tidak boleh hilang, restart sistem di tengah perjalanan harus melanjutkan dengan benar), dan akurasi kalkulasi tarif (harus eksak, bukan aproksimasi).

3. Quantitative Analysis

   Estimasikan QPS permintaan perjalanan puncak (perjalanan harian / 86400 × faktor puncak), QPS update lokasi (pengemudi aktif × update per detik), ukuran storage lokasi (driver_id + lat + lon + timestamp × pengemudi aktif, disimpan sementara di Redis), storage record perjalanan (metadata perjalanan × perjalanan per hari × tahun retensi), dan jumlah pengemudi aktif per kota saat jam puncak. Turunkan volume tulis update lokasi sebagai beban operasional dominan.

4. API Design

   Tentukan operasi API untuk meminta perjalanan (penumpang menentukan jemput/tujuan), menerima perjalanan (pengemudi menerima penawaran match), memperbarui lokasi pengemudi (tulis sering dari aplikasi pengemudi), mengambil lokasi pengemudi saat ini (penumpang polling atau subscribe), memperbarui state perjalanan (pengemudi memulai perjalanan, mengakhiri perjalanan), dan mengambil ringkasan perjalanan beserta tarif. Sertakan protokol update lokasi (REST vs. WebSocket), state machine perjalanan (requested → matched → accepted → in-progress → completed), dan kasus error (tidak ada pengemudi tersedia, pengemudi membatalkan).

5. High-Level Design

   Usulkan komponen utama: ride service (mengelola siklus hidup permintaan perjalanan), location service (meng-ingest update lokasi pengemudi frekuensi-tinggi dan memelihara indeks geospasial), matching service (menemukan pengemudi terdekat yang tersedia, mengirim penawaran match), notification service (mendorong penawaran match ke aplikasi pengemudi, mengirim update ke penumpang), trip service (melacak state perjalanan aktif, memicu kalkulasi tarif saat selesai), dan fare service (menghitung tarif dari jarak dan durasi). Telusuri sebuah perjalanan dari permintaan hingga selesai, mengidentifikasi layanan mana yang menangani setiap transisi state.

6. Additional High-Level Design Prompts

   Bahas tiga area lanjutan: (1) Pemulihan pembatalan pengemudi, jika pengemudi menerima lalu membatalkan, bagaimana sistem mengantrikan ulang permintaan penumpang dan menemukan pengemudi tersedia berikutnya tanpa penumpang perlu meminta ulang; (2) Surge pricing, bagaimana ketidakseimbangan permintaan/pasokan real-time per sel geografis dihitung dan dicerminkan dalam estimasi tarif yang ditampilkan ke penumpang saat permintaan; (3) Riwayat perjalanan dan struk, bagaimana record perjalanan diarsipkan untuk akuntansi, penyelesaian sengketa, dan pelaporan pajak mengingat volume perjalanan.

7. Deep Dives

   Deep dive ke tiga area: (1) Location service dan pencocokan geospasial, pengemudi mengirim lokasi setiap 4-5 detik; disimpan di Redis GEO (GEOADD) dengan TTL pendek; matching service menjalankan GEOSEARCH untuk pengemudi tersedia dalam radius; state ketersediaan pengemudi dipelihara sebagai Redis hash (driver_id → {status: available/on_trip, vehicle_type}); matching mengirim top-N kandidat diurutkan berdasarkan ETA (bukan hanya jarak); estimasi ETA menggunakan graph jalan (bukan jarak garis-lurus); (2) Berbagi lokasi real-time selama perjalanan, setelah di-match, penumpang butuh update lokasi pengemudi langsung; dua opsi: (a) penumpang polling location service setiap 3s (sederhana, beban baca tinggi); (b) channel WebSocket: penumpang subscribe ke channel lokasi pengemudi; location service mem-publish setiap update pengemudi ke channel; klien penumpang memperbarui pin peta; bahas mana yang lebih skalabel; (3) Kalkulasi tarif, tarif = base_fare + (distance_rate × km) + (time_rate × menit); jarak dihitung dari trace GPS (jumlah jarak haversine antara titik lokasi pengemudi berurutan selama perjalanan); tarif bersifat deterministik mengingat trace GPS; hitung ulang jika drift GPS terdeteksi (buang lompatan tak-masuk-akal > 100m/s).

8. Final Review Handoff Readiness

   Ringkas keputusan desain utama: location service (Redis GEO, interval update 4-5s), matching (GEOSEARCH terurut-ETA), pelacakan real-time (channel WebSocket per perjalanan), state machine dan durabilitas perjalanan, kalkulasi tarif (jumlah trace GPS dengan filtering drift). Soroti dua pertanyaan terbuka (konsistensi state ketersediaan pengemudi saat network partition, dapatkah pengemudi di-double-book?, dan kalibrasi ambang drift GPS) dan usulkan rollout bertahap: location service + matching dulu, lalu pelacakan real-time, lalu surge pricing.

Preview solusi

Desain Uber, Solusi Referensi Cakupan Problem Sebuah platform ride-hailing (pemesanan tumpangan) di mana rider meminta tumpangan, sistem melakukan matching mereka dengan driver terdekat yang tersedia, kedua pihak saling melacak posisi secara real time selama perjalanan, dan fare (tarif) dihitung serta ditagih di akhir. Di luar cakupan: pengiriman makanan (Ub…