Week 10 · Day 1 · 2026-09-28 MON · CORE · requirements/API/data model/HLD

Uber HLD: fare, ride request, location update, candidate match

08:50-10:55 system design14:30-16:15 Intervals20:30-21:15 recall/mock

今日目标

Build the Uber happy path with driver location as a fresh projection and Ride/DriverOffer as durable state.

08:50-09:00Set target
One sentence: match a rider to exactly one available nearby driver under stale GPS.
09:00-10:05Blank-page attempt + Hello Interview reading
Read Uber framing through HLD and four functional paths.
10:05-10:45Decision note
Bind driverId write key, geocell candidate index, fare estimate trust boundary, and ride status.
10:45-10:55Spoken close
Two-minute English HLD: fare -> request -> match -> offer -> accept.
14:30-16:15NeetCode Tag · Intervals
Exactly three contiguous slots; each slot is 30m solve + 5m evidence.
20:30-21:15Recall / Mock
20:30-21:15 English recall: explain which state is durable and which state is projection.

Live canonical source anchors

Daily anchors retain the original Hello Interview heading text.

ProjectExact canonical source headingDispositionUse
UberUnderstanding the Problemrequired readingframe ride-sharing and on-demand matching
UberFunctional Requirementsrequired readingfare, ride request, nearby match, driver accept/decline
UberNon-Functional Requirementsrequired readinglow-latency match, strong matching consistency, peak throughput
UberThe Set Uprequired readingcandidate framing and below-the-line scope
UberPlanning the Approachrequired readingrequirements to entities to API to HLD
UberDefining the Core Entitiesrequired readingRider, Driver, Fare, Ride, Location
UberAPI or System Interfacerequired readingfare, ride, location update, accept/deny endpoints
UberHigh-Level Designrequired readingRide Service, Location Service, Matching Service, Notification Service
Uber1) Riders should be able to input a start location and a destination and get an estimated farerequired readingfare estimate path and trust boundary
Uber2) Riders should be able to request a ride based on the estimated farerequired readingrequested ride creation before matching
Uber3) Upon request, riders should be matched with a driver who is nearby and availablerequired readingcandidate retrieval and availability filter
Uber4) Drivers should be able to accept/decline a request and navigate to pickup/drop-offrequired readingoffer, accept/deny, navigation state

DDIA decision links

Week 10 decisionExact DDIA subsectionDesign consequence
Uber driver location writes should be partitioned by what key?Ch7 - 键值数据的分片Driver location is keyed by driverId for writes, but projected into geocell indexes for proximity search.
Why does geohash/S2 prefix help proximity search but risk hot zones?Ch7 - 按键的范围分片Range-like geo prefixes support neighbor scans, but city centers must be split and load-shed by cell.

Algorithm block

SlotProblemPatternInvariantBug riskTimeSpace
1Missing Ranges
NEW · 30m solve + 5m evidence
boundary scanTrack the next expected integer between lower and upper.Overflow at upper + 1; empty nums.O(n)O(1)
2Remove Interval
NEW · 30m solve + 5m evidence
interval subtractionEach interval emits left/right residue outside the removed range.Closed/open endpoint confusion.O(n)O(n) output
3Add Bold Tag in String
NEW · 30m solve + 5m evidence
merge marked spansAll matched spans are merged before rendering tags.Adjacent spans should merge.O(n * words)O(n)

Output and repair

DeliverableUber HLD with Rider/Driver/Fare/Ride/Location/DriverOffer schema and API trust boundaries.
Repair ruleIf location table is treated as assignment truth, rewrite the design so Ride/DriverOffer own assignment state.
ArtifactsUber Chinese deep script Uber Chinese audio Uber English recall Uber recall PDF
English recallEnglish recall: defend freshness, reservation, race recovery, fairness, and observability without reading notes.
Local study materials
Detailed lecture notes, audio, recall scripts, PDFs, Staff Q&A, and mock packs are archived locally and are intentionally not published on this site.