verdict
Candidate delivered a strong hard-level ride-hailing design across the full 2400s budget. They locked immediate single-rider scope early , set asynchronous service boundaries , and built a city-isolated geo and dispatch core with credible and hot-cell-aware nearby-driver lookup . Assignment races and conditional claim semantics were handled cleanly . Reliability covered pricing versions, idempotency, failover, and durable payments, but atomic publication intent (outbox) required a hint on the commit-success/publish-fail probe , matching the only shadow deduction. They closed with failover/durability cases and a coherent city-isolation vs durable-trip-transition tradeoff . Recommendation: advance, with the next round stress-testing unprompted dual-write durability and edge workflows (scheduled rides, partial publish failure drills).
recommendation
Advance
Scores of 4/5/4/4 on requirements, architecture-scale, reliability, and communication with an architecture-scale 5 demonstrate hire-bar system design for a hard ride-hailing prompt. The only material deduction is a hinted outbox on atomic publication; that is a coachable gap, not a core geography/dispatch failure. Advance to a deeper reliability and consistency round.
Decision support only — the final call is yours.
rubric breakdown
Score 4: Strong framing of immediate single-rider scope and service ownership; scheduled/pooled rides accepted then not carried into the detailed design.
Score 5: City isolation, geohash neighborhoods, exact-distance ranking, hot-cell split, and city-plus-prefix sharding were concrete and appropriate for dense regions.
Score 4: Assignment races, price versions, idempotency, failover covered; −0.5 shadow deduction for needing a hint before atomic publication/outbox.
Score 4: Clear multi-stage narrative and closing tradeoff summary; one probe needed a hint without derailing the overall structure.
Design a ride-hailing platform
4.3/5harddistributed-systemsgeodispatch40m 00s
on question
proctoring & anomalies
This is an illustrative sample. No real candidate integrity assessment is published.
strengths
+ Clear requirements and API framing: immediate single-rider scope, core workflow ownership across gateway, trip, location, dispatch, payments, and notifications
+ Excellent scale architecture: regional ingress, city isolation, geohash lookup, exact-distance ranking over bounded cells, hot-cell splitting, city-plus-prefix sharding
+ Solid dispatch correctness: conditional driver assignment and assignment-race handling
+ Reliability coverage of quoted price versions, idempotency keys, failover, and retryable payment side effects
+ Coherent end-to-end narrative from scope through geo, dispatch, reliability, operations, and tradeoffs
growth areas
− Atomic publication / outbox — Lead with transactional outbox (or equivalent) for commit-success/publish-fail without interviewer prompting; treat durable intent + deduplicated consumers as default for trip state transitions.
− Scheduled / deferred rides — After accepting immediate-only scope, briefly sketch how scheduled rides would reuse or extend trip ownership, dispatch windows, and pricing so the design lineage is explicit.
− Hint independence on reliability probes — On dual-write probes, enumerate failure modes (DB commit vs publish) and pick an atomic pattern before asking for confirmation.