01Rider सबसे पहले क्या देखता है — commit करने से पहले एक price?
Riders pickup और destination डालते हैं और ride request करने से पहले एक fare estimate (price + ETA) पाते हैं।
मुफ़्त पूरी गाइड
Uber (Ride Hailing)
Uber (Ride Hailing) डिज़ाइन करें। इसमें Geospatial indexing trade-off: geohash vs quadtree vs S2/H3 cells for storing and querying driver locations, High-frequency driver location ingestion: update...
00
अभ्यास checkpoints
Interview की लय संक्षिप्त रहती है, ताकि page असली design निर्णयों पर ध्यान लगा सके.
- 01Scope स्पष्ट करें
- 02Requirements + scale
- 03API + data model
- 04Architecture बनाएँ
- 05Deep dive
- 06Trade-off निर्णय
01
Requirements जो design तय करते हैं
सिर्फ requirements मत बताइए — पूछिए। हर card एक design constraint को उस clarification सवाल से जोड़ता है जो आप architecture बनाने से पहले बोल सकते हैं.
Functional requirements
02Request tap करने के बाद क्या होता है — match कितनी जल्दी वापस आना चाहिए?
Riders अनुमानित fare पर एक ride माँगते हैं और करीब एक मिनट के भीतर एक पास के available driver से match हो जाते हैं। अगर कोई driver available न हो, तो उन्हें एक साफ़ failure मिलता है।
03Driver की तरफ़ क्या होता है?
Drivers online जाते हैं, location pings भेजते हैं, और एक बार में एक ही ride offer पाते हैं, जिसे स्वीकार या अस्वीकार करना होता है। स्वीकार करने पर, वे pickup और drop-off तक navigate करते हैं।
04क्या rider matching के बाद cancel कर सकता है, और driver को क्या अनुभव होता है?
हाँ। एक cancellation के बाद, driver तुरंत नई rides के लिए available हो जाता है, और system record रखता है कि किसने और कब cancel किया।
05क्या rider driver को live आते हुए देखता है?
हाँ। Driver की location सिर्फ़ ride active रहते matched rider तक stream होती है। बाकी सब मोटी-मोटी availability देखते हैं, कभी एक trackable trail नहीं।
06Matching window के भीतर कोई driver accept नहीं करता — फिर क्या?
Request retry guidance के साथ साफ़-साफ़ fail होती है — मिनट के भीतर एक पक्का 'नहीं' उस spinner से बेहतर है जो कभी हल नहीं होता।
Scope से बाहरRatings (rider और driver) · Scheduled rides और ride tiers (X/XL/Comfort) · Surge pricing की mechanics और payment settlement
Non-functional requirements
01क्या एक driver कभी एक साथ दो rides पा सकता है?
Matching strongly consistent है: एक driver एक समय में ज़्यादा से ज़्यादा एक active offer या ride रखता है — कभी double-dispatch नहीं।
02Driver locations कितनी fresh होनी चाहिए?
Drivers online रहते हुए हर कुछ seconds में ping करते हैं; proximity search कुछ seconds पुराना data देख सकती है, कभी minutes पुराना नहीं।
03हमें driver location updates के किस peak rate के लिए design करना चाहिए?
हम एक जान-बूझकर तय की stress ceiling के लिए design करते हैं: दुनिया भर में 10M drivers online, हर एक ~5 सेकंड में ping करता हुआ। यह करीब 2M location writes प्रति सेकंड बनता है।
04जब एक stadium ख़ाली होता है तब क्या होता है?
एक ही इलाके से ~100K ride requests का burst queue होकर सहजता से निकल जाता है — पास के zones और दूसरे शहर अप्रभावित रहते हैं।
05हर step कितना तेज़ महसूस होना चाहिए?
Fare estimate कुछ seconds में; match (या एक साफ़ failure) end to end लगभग एक मिनट में।
पूछते रहिए — interview एक बातचीत है
असली interview एक साफ list से कहीं गहरा probe करते हैं. ये scope सवाल उन्हें अलग करते हैं जो problem को कुरेदते हैं बनाम जो रटते हैं.
- Ride history और driver location trails कितने समय store रहने चाहिए — और क्या एक driver का trail request पर deletable होना चाहिए?
- क्या हमें GPS spoofing या matching को game करते drivers संभालने हैं, या fraud कहीं और filter होता है?
- क्या यह launch पर एक शहर है या पहले दिन से global — और क्या हर region का data उसी region में रहना होगा?
- क्या कोई match success rate है जिसके लिए हम contractually बँधे हैं, या एक मिनट के भीतर एक स्पष्ट failure स्वीकार्य है?
- क्या surge pricing और ratings scope से बाहर हैं?
02
वे numbers जो architecture निर्णय मजबूर करते हैं
हर estimate को एक दबाव मानिए जो किसी component को justify करता है: cache, queue, partition, replica, worker pool, या fallback path.
Location writes की बौछार
दुनिया भर में 10M drivers online का stress ceiling × हर 5 s में 1 ping10,000,000 ÷ 5 ≈ 2M writes/s
कोई relational database इसे नहीं झेल सकता — locations एक in-memory geo index (geohash/H3 buckets) में TTL eviction के साथ जाती हैं।
Proximity lookup cost
pickup point एक geohash cell में आता है; search radius को cover करने का मतलब वह cell साथ में उसके 8 पड़ोसी — एक 3 × 3 grid, 9 cells9 cell reads × प्रति in-memory lookup 1 ms से काफ़ी नीचे ≈ single-digit milliseconds
Geohashing 'मेरे पास कौन है' को table scan के बजाय मुट्ठी भर key lookups में बदल देता है।
Concert burst
~10 minutes में एक ही neighborhood से ~100K requests100,000 ÷ 600 s ≈ एक zone में 170 matches/s
Matching queue को geo zone से partition करें — spike एक zone के consumers को संतृप्त करता है, पूरे शहर को नहीं।
Offer budget
60 s के भीतर match; हर offered driver को respond करने के लिए ~10 s60 s ÷ 10 s ≈ deadline से पहले 5-6 drivers आज़माए जाते हैं
10-सेकंड का offer lock सीमित कर देता है कि आप एक मिनट के अंदर कितने drivers आज़मा सकते हैं। इसलिए offers छिड़कने की बजाय candidates को अच्छे से rank करो।
Phantom-driver cleanup
Location entries आख़िरी ping के 15-30 s बाद expire होती हैं — यह 5 s cadence पर 3-6 चूके हुए pings हैं15-30 s ÷ प्रति ping 5 s = 3-6 silent intervals → entry expire; एक crashed driver बदतर हालत में ~30 s के भीतर offers पाना बंद कर देता है
जो drivers crash या offline हो जाते हैं वे index से अपने-आप ग़ायब हो जाते हैं — कोई cleanup job नहीं, ghosts को कोई offers नहीं।
निर्णय उदाहरण
Numbers
यह system दो बहुत अलग loads उठाता है। Drivers करीब 2M location writes प्रति सेकंड stream करते हैं। हर ride match को बस एक मिनट के भीतर कुछ पास के candidates चाहिए।
मेरी पसंद
Driver locations को एक in-memory geo index (geohash/H3 buckets) में एक short TTL के साथ रखो, ताकि जो drivers ping करना बंद कर दें वे बस गायब हो जाएँ। Matching पास के candidates खींचता है और एक बार में एक driver को ride offer करता है, उस driver को करीब 10 सेकंड के लिए lock करके। Accept ride जीत लेता है; एक timeout या decline lock छोड़ देता है और अगले candidate को offer मिलता है। एक spike के दौरान, ride requests एक ऐसे queue में इंतज़ार करती हैं जो इलाके से partition है, इसलिए एक stadium का खाली होना उस मोहल्ले को धीमा करता है, पूरे शहर को नहीं।
बचें
जो मैं नहीं करूँगा: हर location ping को main database में लिखना और पास के drivers ढूँढने के लिए उसे scan करना। 2M writes प्रति सेकंड पर, वह प्लस scans इसे मार देते हैं। मैं एक ही ride कई drivers को एक साथ बिना lock के भी offer नहीं करूँगा, क्योंकि दो accepts एक साथ आ सकते हैं और दोनों drivers सोचते हैं कि उन्हें काम मिला। और मैं पहले ही दिन matching system को shard नहीं करूँगा। पहले per-zone rate नापो; बहुत जल्दी sharding उस capacity को जोड़े बिना failure modes जोड़ती है जिसकी आपको सचमुच ज़रूरत हो।
कब बदलें
अगर match quality speed से ज़्यादा मायने रखे, जैसे pooled rides या batching, तो मैं कुछ सेकंड के लिए requests इकट्ठा करूँगा और उन्हें एक-एक करके नहीं, छोटे batches में match करूँगा।
03
Architecture path
पहले एक पूरी तस्वीर, फिर हर path को अपना अलग diagram — write path और read path अलग traffic ढोते हैं और अलग components justify करते हैं.
पूरी तस्वीर
Overview — हर component
Driver pings सीधे in-memory geo index में बहते हैं; matching उससे पास के candidates पढ़ता है और एक बार में एक driver को rides offer करता है। Ride की सच्चाई database में रहती है — index disposable है।
Path 1
Request path — estimate, request, match
पहले fare, फिर request। Matching मुट्ठी भर पास के candidates खींचता है और एक बार में एक driver को offer करता है; 10-second lock double-dispatch रोकता है और जब कोई driver offer अनदेखा करता है तो अपने-आप आगे बढ़ जाता है।
Path 2
Location path — writes की बौछार
करीब 2M pings प्रति second memory में आते हैं, geohash/H3 cells में bucket होकर; entries 15-30 seconds बाद expire हो जाती हैं ताकि जो drivers ping करना बंद कर दें वे अपने-आप ग़ायब हो जाएँ।
04
API और data model
optimize करने से पहले contract को inspectable बनाइए: endpoints, entities, ownership, retries, और state.
POST/fare
req{ pickup, destination }
res200 { fare_id, estimated_fare, eta }
route + ETA के लिए mapping provider को call करता है; estimate save हो जाता है ताकि ride request उसे reference कर सके।
POST/rides
req{ fare_id }
res201 { ride_id, state: requested } · 404 fare expired
Matching शुरू करता है; rider को match result push होता है (या वह poll करता है)।
POST/drivers/location
req{ lat, lng }
res200
Driver identity session token से आती है, कभी request body से नहीं। High-frequency write सीधे geo index में।
PATCH/rides/{ride_id}
req{ accept | decline }
res200 ride · 409 offer expired
Accept offer को atomically flip करता है; decline या 10-second timeout driver को release कर देता है और अगला candidate offer पाता है।
Core entities
Riderrider_id (PK) · payment_profile
Driverdriver_id (PK) · vehicle · status: offline/available/offered/on_trip
status field ही double-dispatch guard है: सिर्फ़ एक available driver ही offer पा सकता है, और यह flip atomic है।
Farefare_id (PK) · pickup · destination · estimated_fare · eta
estimate के समय बनता है; ride request fare_id को reference करती है ताकि quoted price चुपचाप बदल न सके।
Rideride_id (PK) · rider_id · driver_id · fare_id · state: requested/matched/in_progress/completed
DriverLocationdriver_id · lat/lng · updated_at
in-memory geo index (TTL वाले geohash/H3 cells) में रहता है, relational store में नहीं — यह disposable data है।
05
Deep dive दिशाएँ
interview के आखिरी एक-तिहाई के लिए एक lane चुनें. हर lane आपको topic, वह interviewer सवाल जिसका जवाब देना है, और बचने वाला failure mode देती है.
Location writes की बौछार
Ask
10M drivers हर 5 seconds में ping करते हैं। 2M writes प्रति second कहाँ जाते हैं, और आप 'इस pickup के पास कौन है' का जवाब कैसे देते हैं?
Answer
Pings एक in-memory geo index में जाते हैं, कभी relational database में नहीं। वह 2M writes प्रति second नहीं झेल सकता। हर location को एक geohash या H3 cell में bucket करो एक short TTL के साथ। यह ढूँढने के लिए कि pickup के पास कौन है, उस cell को उसके 8 neighbors समेत पढ़ो — नौ memory lookups single-digit milliseconds में, कोई table scan नहीं।
बचें
Pings को main database में लिखना और proximity के लिए scan करना — इस rate पर यह मर जाता है।
एक driver को कभी दो बार dispatch न करें
Ask
दो ride requests एक ही पल में एक ही पास के driver को चाहती हैं। ठीक एक कैसे जीतता है?
Answer
Driver को एक short exclusive lock से पकड़ो। यह एक atomic compare-and-set है, तो ठीक एक request जीतती है और हारने वाला अपने अगले candidate पर चला जाता है। असली ride state database रखता है: accept driver को on-ride में पलट देता है, और एक cancellation उसे वापस available कर देता है ताकि कोई stale hold न टिके।
बचें
बिना lock के कई drivers को एक साथ offer करना — दो accepts दोनों सोचते हैं वे जीत गए।
Driver जवाब नहीं देता
Ask
Offered driver request को अनदेखा कर देता है। second 10 पर क्या होता है, और ride फिर भी एक मिनट के भीतर कैसे match होती है?
Answer
Offer एक 10-second lock है, कोई blocking wait नहीं। 10वें second पर यह अपने आप expire हो जाता है और matching अगले ranked driver पर चला जाता है। हर एक करीब 10 seconds पर, 5-6 drivers 60-second budget के अंदर फिट बैठते हैं। इसीलिए तुम candidates को ध्यान से rank करते हो, हर जगह offers छिड़कने के बजाय।
बचें
एक unresponsive driver पर ride को रोकना बजाय एक lock TTL के जो आगे बढ़ जाता है।
एक stadium ख़ाली होता है
Ask
मिनटों में 100K लोग एक neighborhood से rides request करते हैं। आप बाक़ी शहर को अप्रभावित कैसे रखते हैं?
Answer
Matching queue को geo zone से partition करो। 10 minutes में 100K requests बस करीब 170 matches प्रति second हैं। यह उस एक zone के consumers को saturate कर देता है जबकि हर दूसरा zone सामान्य रूप से drain होता रहता है। Hot zone को ईमानदार queueing दिखती है — एक लंबा wait या एक साफ़ failure। बाकी शहर ठीक चलता है।
बचें
एक global matching queue — एक local spike citywide outage बन जाता है।
Phantom drivers
Ask
एक driver app available मार्क रहते हुए crash हो जाता है। वे कब तक offers पा सकते हैं, और उन्हें क्या साफ़ करता है?
Answer
हर location entry आख़िरी ping के 15-30 seconds बाद expire हो जाती है। 5-second की cadence पर यह बस 3-6 छूटे pings हैं, तो एक crashed driver अपने आप index से बाहर हो जाता है। किसी cleanup job की ज़रूरत नहीं। एक ghost सबसे ज़्यादा करीब 30 seconds तक offers पाता रह सकता है।
बचें
Location entries पर कोई TTL नहीं — offers उन drivers को जाते रहते हैं जो एक घंटा पहले चले गए।
अभ्यास के लिए तैयार?
Uber (Ride Hailing) को ज़ोर से समझाइए और अपनी व्याख्या पर AI scoring पाइए.