Cab Booking System – Low Level Design Interview Practice
Practise the Cab Booking System low level design problem the way an LLD round actually runs. You are asked for requirements first, then a class model, and then to extend the design when a new requirement lands part way through – the follow-up that separates a design that was memorised from one that was understood.
The round checks the things interviewers grade: whether your classes carry single responsibilities, whether you reached for a design pattern or reinvented one, whether the design absorbs a new requirement without rewriting what exists, and whether you can explain a trade-off out loud. Feedback covers class modelling, SOLID principles, use of patterns, extensibility and communication.
What this question is really testing
Matching and pricing. Driver-to-rider assignment and surge are the two decisions that must stay swappable, and the trip state machine is what holds them together.
Requirements to establish first
- Find available drivers near a pickup point.
- Match a rider to a driver, and reassign when the first declines or times out.
- Price by distance, time, vehicle class and demand.
- Track a trip through requested, accepted, arrived, in progress, completed.
- Ingest driver location updates continuously, and keep them queryable by proximity.
Core classes
- Rider / Driver – The two parties. A driver also carries availability and a current location.
- Trip – Pickup, drop, fare, status. The thing the state machine moves.
- TripState – Requested, accepted, arrived, started, completed, cancelled - with who may cancel differing per state.
- LocationService – Proximity search over driver locations. Usually a geohash or quadtree, and worth naming.
- MatchingStrategy – Nearest driver, highest rating, or lowest estimated pickup time.
- PricingStrategy – Base plus distance plus time, composed with a surge multiplier.
Design patterns that apply
- Strategy – Matching and pricing, independently. Surge is a separate concern composed onto the base fare, not a branch inside it.
- State – Trip lifecycle, where cancellation rules differ by state - free before the driver arrives, charged after.
- Observer – Both parties and the fare estimator react to trip state changes.
Follow-up questions to expect
- A driver accepts and then goes offline. Where does the trip go, and does the rider rejoin the queue at the front?
- Surge is 2.1x when the rider requests and 1.4x when the driver accepts. Which price holds, and where is that decided?
- Proximity search over a city of 50,000 drivers. Name the structure and its update cost.
Where candidates lose marks
- Scanning all drivers to find the nearest, with no spatial index named.
- Surge as a field on Trip rather than a composed pricing rule, so it cannot be explained or audited.
- One cancellation rule for every state, which gets the free-cancellation window wrong.