Wawancara Desain Sistem: Rancang Uber
"Rancang Uber" adalah salah satu soal desain sistem paling umum karena menyentuh pengindeksan geospasial, streaming lokasi real-time, pencocokan (matching), dan throughput tulis yang tinggi sekaligus. Pewawancara tidak mencari arsitektur Uber yang sebenarnya — mereka ingin melihat Anda membatasi ruang lingkup masalah, membuat pilihan yang bisa dipertanggungjawabkan, dan bernalar tentang skala secara lisan.
Kerjakan dengan urutan yang disengaja: perjelas kebutuhan, perkirakan skala, sketsa entitas dan API inti, rancang data serta jalur pencocokan, lalu bahas titik-titik hambatan dan trade-off. Panduan di bawah mengikuti urutan itu sehingga Anda melatih strukturnya, bukan hanya jawabannya.
1. Memperjelas kebutuhan
Pisahkan kebutuhan fungsional dari non-fungsional, dan kunci ruang lingkup sebelum mendesain. Penumpang memesan perjalanan dan melihat pengemudi mendekat secara real-time; pengemudi online dan menerima permintaan di sekitarnya; sistem mencocokkan mereka dan melacak perjalanan hingga selesai.
- Fungsional: memesan perjalanan, mencocokkan dengan pengemudi terdekat, melacak perjalanan secara live, kalkulasi tarif, riwayat perjalanan.
- Non-fungsional: pencocokan latensi rendah (beberapa detik), ketersediaan tinggi, pembaruan lokasi real-time, konsistensi bahwa satu pengemudi hanya ditugaskan ke satu penumpang.
- Di luar ruang lingkup (katakan secara eksplisit): internal pemrosesan pembayaran, rating, ML tarif lonjakan — sebutkan saja, lalu tunda.
2. Memperkirakan skala
Angka perkiraan kasar membenarkan pilihan-pilihan berikutnya. Anggap ~10 juta pengemudi aktif harian mengirim ping lokasi setiap 4 detik — itu berarti ~2,5 juta penulisan per detik data lokasi, beban kerja yang didominasi penulisan dan langsung menyingkirkan tabel relasional sederhana sebagai jalur utama (hot path).
3. Komponen inti dan API
Sketsa layanan-layanan dan alur permintaannya. Jaga jalur pencocokan tetap independen dari penyimpanan perjalanan yang persisten agar masing-masing dapat diskalakan sesuai karakteristiknya sendiri.
- Layanan lokasi: menerima ping pengemudi, menyimpan posisi terkini dalam indeks geospasial in-memory.
- Layanan pencocokan: saat ada permintaan perjalanan, mencari pengemudi online terdekat dan menugaskan salah satunya.
- Layanan perjalanan: catatan persisten dari siklus hidup perjalanan (diminta → dicocokkan → berlangsung → selesai).
- Notifikasi/streaming: mengirim posisi pengemudi secara live ke penumpang (WebSocket/long-poll).
4. Pencocokan geospasial — inti dari masalah ini
Inilah yang paling ingin didengar pewawancara. Menyimpan lat/long mentah dan memindainya adalah O(n); Anda butuh indeks spasial. Jelaskan quadtree atau geohashing: membagi peta menjadi sel-sel sehingga 'cari pengemudi di dekat titik ini' menjadi pencarian beberapa sel saja, bukan pemindaian penuh.
Geohashing mengenkode suatu wilayah menjadi string pendek di mana prefiks yang sama menandakan kedekatan spasial, sehingga 'terdekat' menjadi query berbasis prefiks. Sel-sel pengemudi saat ini disimpan dalam penyimpanan in-memory (misalnya Redis) untuk pembacaan cepat dan pembaruan yang sering; granularitas sel adalah trade-off yang dapat disetel antara presisi dan fan-out query.
5. Skalabilitas dan titik hambatan
Sebutkan titik-titik tekanan dan cara Anda meredakannya. Aliran 2,5 juta penulisan lokasi per detik adalah yang paling dominan.
- Lakukan sharding pada indeks lokasi secara geografis — pengemudi dan penumpang di satu kota ditangani oleh shard yang sama, sehingga pencocokan tetap lokal.
- Serap lonjakan penulisan dengan penyimpanan in-memory dan penulisan persisten asinkron; Anda tidak perlu setiap ping masuk ke database persisten.
- Pastikan satu pengemudi-satu penumpang dengan penugasan atomik (lock atau update bersyarat) untuk menghindari pemesanan ganda.
- Gunakan message queue (Kafka) antara ingesti lokasi dan konsumen hilir untuk mendekopel lonjakan.
6. Trade-off yang perlu diucapkan
Tutup dengan menyebutkan tegangan yang dihargai pewawancara: konsistensi kuat vs eventual (penugasan pengemudi harus kuat; tampilan lokasi bisa eventual), kecepatan in-memory vs durabilitas, serta presisi ukuran sel vs fan-out query. Menyatakan hal ini secara eksplisit adalah pembeda antara jawaban yang lolos dan jawaban yang kuat.
Latih desain sistem Uber dengan bantuan real-time
Asisten wawancara desain sistem dari Natively dapat membantu Anda tetap terstruktur selama sesi live — menyarankan dimensi berikutnya yang perlu dibahas dan menampilkan trade-off secara real-time, semuanya di perangkat Anda sendiri.
