Car Rental System

Vehicle Rental Management Platform

Design a car rental system that books cars by category and date range across branches, supports one-way rentals and maintenance blocks, never double-books a car, and bills at return.

Overview

A rental company has branches, each with cars in a few categories. A customer asks for a category, a pickup branch, a return branch and a date range. The system must find a car that is free for the whole range and will be at that branch when the rental starts, hold it, and later bill the customer for what they actually used.

What makes this harder than a parking lot is time. A car is not simply free or taken: it is free on some days and booked on others, and after a one-way rental it sits at a different branch. The interviewer is listening for three things: an overlap test for date ranges that you can state in one line, a schedule per car that answers 'can this car take this booking?' atomically, and a clear life cycle for a reservation with the illegal moves refused.

Scoping the problem

Does the customer book a category or a specific car? — Decides what search returns — A category; the system picks the car
What is the time unit? — Hours make the overlap math the same but the numbers bigger — Whole days
One-way rentals? — The car's location changes over time — Yes, with a fee
How are cars taken out for service? — Another thing that occupies a car's schedule — A maintenance block on the car's schedule
How is the price made up? — The part that changes most — Daily rate by category, weekly discount, add-ons, late days, one-way fee
Many agents booking at once? — Two bookings must not win the same car — Yes; booking is atomic per car
Payments, licenses, loyalty? — Separate services — Out of scope

Core entities

A Booking is what occupies a car: a customer's rental or a maintenance window. A Reservation is the customer's record: who, which category, which car, and where it is in its life cycle. Keeping the two apart is what lets maintenance use the same schedule and the same overlap test.

The overlap test

Treat each stay as a half-open range [start, end): a car booked for days 1 to 4 is out on days 1, 2 and 3 and free again on day 4. Two stays A and B overlap exactly when A starts before B ends and B starts before A ends.

[1, 4) — [4, 6) — 1 < 6 yes — 4 < 4 no — No: back to back is fine
[1, 4) — [3, 5) — 1 < 5 yes — 3 < 4 yes — Yes
[1, 4) — [0, 10) — 1 < 10 yes — 0 < 4 yes — Yes: B contains A
[5, 8) — [1, 4) — 5 < 4 no — 1 < 8 yes — No

Half-open ranges avoid off-by-one arguments: the length is end minus start, and a return day can be the next pickup day.

Where the car is

A one-way rental moves the car. So 'is this car free?' also asks 'will it be at the pickup branch?' and 'will the next rental still find it where it expects?'. Car._fits walks the car's sorted bookings once and checks all three.

The demo's trace, with economy cars E1 and E2 both starting at SFO:

1 — SFO to SFO, days [0, 3) — E1 — First car that fits
2 — SFO to OAK, days [1, 4), GPS — E2 — E1 overlaps
3 — SFO to SFO, days [2, 3) — refused — Both cars are out on day 2
4 — OAK to OAK, days [5, 8) — E2 — E1 is at SFO; E2 was left at OAK
5 — SFO to SFO, days [5, 6) — E1 — E2 is at OAK
6 — Maintenance on E1, days [3, 5) — E1 — Fits the gap between steps 1 and 5

The reservation life cycle

The code holds the allowed moves in a dictionary, ALLOWED, and one method, _move, checks it under the service lock. A table of transitions is easier to read and test than a class per state when states carry no behavior of their own.

Billing at return

The bill is computed when the car comes back, from the booked range and the actual return day, by a PricingStrategy. The service holds no formula.

Rental — daily rate × booked days — 7000 × 7 = 49000
Weekly discount — 10 percent off the rental when 7 days or more — -4900
Add-ons — sum of add-on daily rates × booked days — 0
Late days — 1.5 × daily rate per day past the end — 10500
One-way fee — flat when dropoff differs from pickup — 0
Total — 54600

These rates are example configuration, not industry figures; the point is that each line is one rule the strategy owns.

What you will be able to do

State the half-open overlap test and use it to check a car's schedule.
Explain why a one-way rental makes location part of availability, and check it with the previous and next booking.
Book atomically per car so two agents never get the same car, without one global lock.
Model the reservation life cycle as a transition table and refuse illegal moves.
Bill at return with a swappable pricing strategy and explain each line.

Functional requirements

reserve(customer, category, pickup, dropoff, start, end, add_ons) picks a car of the category that is free for [start, end), is at the pickup branch at start, and does not break its next booking
One-way rentals: the car is at the dropoff branch after the rental ends
block_for_maintenance(car, start, end) occupies the car's schedule at its current branch
cancel frees the car; pick_up and return_car move the reservation through its states
return_car(rid, day) returns a bill: rental, weekly discount, add-ons, late days, one-way fee, total
Illegal moves (return twice, cancel after pickup) are refused

Non-functional requirements

A car is never booked for two overlapping stays, even when many agents book at once
Booking locks one car at a time; different cars never wait on each other
Pricing rules change by adding or swapping a PricingStrategy, not by editing the service
Days and money are integers, so tests are exact

Interview questions

Two agents book the last SUV for the same dates at the same moment. What happens?
A customer returns the car two days late, and the car was booked by someone else for the next morning. How do you handle it?
How would you send cars for service every N miles?
Search is slow with thousands of cars. How do you speed it up?