This question evaluates data modeling, transactional integrity, concurrency control, REST API and workflow design, and system scalability within the car rental domain in the System Design category.
Design a car rental platform focusing on core entities, relational database schema, and API interfaces. Define key entities and relationships (e.g., customer, vehicle, vehicle_type, branch/location, inventory/unit, reservation, rental/contract, payment, pricing rule, promotion, insurance, availability/hold, staff, damage report). Propose table definitions with primary/foreign keys, unique constraints, and essential indexes (e.g., availability lookups by location and date). Describe workflows and consistency requirements for: search availability by location and date/time windows; create/modify/cancel reservation with holds to prevent double-booking; pick-up (vehicle assignment, contracts, inspection) and return (mileage, fuel, damage, late fees); pricing (base rate, mileage, insurance add-ons, taxes, promotions); payments (authorization, capture, refunds). Provide 3–5 representative REST endpoints with request/response fields (e.g., POST /search, POST /reservations, PATCH /reservations/{id}, POST /rentals/{id}/return). Discuss idempotency, pagination, authentication/authorization, concurrency control (row locks or optimistic versioning), and a plan to scale (read replicas, partitioning by branch/region, caching hot availability queries).
Quick Answer: This question evaluates data modeling, transactional integrity, concurrency control, REST API and workflow design, and system scalability within the car rental domain in the System Design category.
Design the backend for a car rental platform (think a regional chain like Hertz or Enterprise). The system lets customers search for available vehicles at a branch over a date/time window, reserve a vehicle type, and pick up and return a specific vehicle. The interview is schema- and API-centric: the interviewer wants to see a clean relational data model, the workflows that read and write it, and the REST surface that drives them.
Your design must cover:
Core entities and relationships
: customer, vehicle, vehicle type, branch/location, inventory unit, reservation, rental contract, payment, pricing rule, promotion, insurance, availability/hold, staff, and damage report.
A relational schema
with primary keys, foreign keys, unique constraints, and the essential indexes (especially for availability lookups by branch and date/time window).
End-to-end workflows and their consistency requirements
for: searching availability; creating, modifying, and canceling reservations without double-booking; pickup (vehicle assignment, contract, inspection) and return (mileage, fuel, damage, late fees); pricing (base rate, mileage, insurance add-ons, taxes, promotions); and payments (authorization, capture, refunds).
3–5 representative REST endpoints
with concrete request/response fields.
Cross-cutting concerns
: idempotency, pagination, authentication/authorization, concurrency control, and a plan to scale (read replicas, partitioning, caching hot availability queries).
Constraints & Assumptions
Use a relational database (PostgreSQL is fine, and you may lean on Postgres-specific features such as range types and exclusion constraints — but be ready to say how you'd emulate them on a DB that lacks them).
All timestamps are stored in UTC; each branch carries local-timezone metadata for display.
Availability is tracked per vehicle type at a branch
; a
specific
vehicle (unit) is assigned only at pickup. This separation is intentional — searching and holding happen at the type level, while overlap safety for a physical car happens at the unit level.
Double-booking must be prevented via transactional holds and/or constraints, including a cleaning/turnover buffer between rentals.
Assume single-currency per branch and a third-party payment processor (PSP) that supports auth/capture/refund.
Clarifying Questions to Ask Guidance
What is the read/write ratio and peak scale? (Search is typically far more frequent than booking — this drives the read-replica and caching decisions.)
Are
one-way rentals
(pickup branch ≠ dropoff branch) in scope? They affect capacity accounting and may carry repositioning fees.
Do we hold inventory at the
vehicle-type
level or must we commit a
specific vehicle
at reservation time? (Assume type-level holds, unit assignment at pickup, unless told otherwise.)
When is payment taken — pre-authorization at reservation, or only at pickup? What deposit policy applies?
Are overbooking and walk-up rentals allowed, or must the schema guarantee zero double-booking?
What are the SLA expectations for search latency and booking success under contention on popular dates?
Part 1 — Entities, Relationships, and Schema
Enumerate the core entities and their relationships, then give concrete table definitions (key columns, PK/FK, unique constraints, check constraints) and the indexes that matter. Pay special attention to how you model type-level availability versus specific-vehicle assignment, and how the schema makes double-booking and overlapping rentals structurally hard rather than relying only on application logic.
What This Part Should Cover Guidance
A complete entity list with correct cardinalities and the FK graph that connects them.
Table DDL with PK/FK, unique constraints (VIN, plate, branch code), and check constraints on enums/status fields.
The deliberate split between type-level availability (search/hold) and unit-level assignment (pickup), and an index plan that makes availability lookups fast.
Part 2 — Workflows and Consistency
Walk through the lifecycle workflows and state exactly where transactions, locks, or constraints enforce correctness: (a) search availability, (b) create/modify/cancel reservation with a hold, (c) pickup with vehicle assignment + inspection, (d) return with charge computation. For each, name the consistency mechanism and what happens on failure.
What This Part Should Cover Guidance
The search path as a pure read (replica-/cache-friendly, no locks) versus the booking path as a guarded write.
A precise double-booking-prevention story: which rows are locked, in what order, and how modify/cancel move the hold.
Pickup as the moment a specific vehicle is committed (with the overlap guard as the final backstop) and return as the moment final charges are computed and the unit is freed.
Failure handling: hold expiry, payment failure, partial completion, and idempotent retries.
Part 3 — Pricing, Payments, and REST API
Define the pricing computation (base rate by duration, mileage/overage, insurance add-ons, fees, promotions, taxes — and how you avoid price drift between quote and booking), the payment lifecycle (authorize → capture → refund/void, with the supporting tables), and 3–5 REST endpoints with concrete request/response bodies (e.g., POST /search, POST /reservations, PATCH /reservations/{id}, POST /rentals, POST /rentals/{id}/return).
What This Part Should Cover Guidance
A line-item pricing breakdown (base, mileage, insurance, fees, promo, tax) with clear unit and rounding semantics, plus the quote-snapshot mechanism.
A payment model that separates an aggregate
payments
row from an append-only transaction ledger, and maps auth/capture/refund to the reservation/rental lifecycle.
Endpoints with realistic request/response fields, correct HTTP verbs, status semantics, and where side-effecting calls accept an
Idempotency-Key
.
Part 4 — Cross-Cutting Concerns and Scaling
Address idempotency (so retried POSTs don't double-book or double-charge), pagination, authentication/authorization (customer vs. staff vs. admin, plus row-level scoping), concurrency control (row locks vs. optimistic versioning, and where each applies), and a concrete plan to scale: read replicas for search, caching of hot availability, and partitioning by branch/region.
What This Part Should Cover Guidance
Idempotency that is correct across retries and partial failures, not just a header that's accepted and ignored.
An authz model with concrete scopes/roles and row-level ownership rules.
A coherent concurrency strategy: where pessimistic locks vs. optimistic
version
/
If-Match
are each the right tool.
A scaling plan that separates the read path (replicas + cache) from the write path (primary), with partitioning and cache-invalidation reasoning.
What a Strong Answer Covers Guidance
Across all parts, a strong candidate keeps the type-level vs. unit-level distinction consistent everywhere (schema, holds, pickup, scaling) rather than letting it blur. They make correctness structural — exclusion constraints, locked-slot transactions, idempotency keys, quote snapshots — instead of hand-waving "the app checks first." They reason about the read/write asymmetry of this domain (search dominates) and let it drive caching and replicas, and they surface the real edge cases (one-way rentals, cleaning buffers, hold expiry races, price drift) without being prompted.
Follow-up Questions Guidance
How would you support
overbooking
(intentionally selling slightly above capacity to absorb no-shows) and walk-up rentals without breaking the no-double-booking guarantee for confirmed pickups?
A popular Friday afternoon at a single branch becomes a hotspot — every booking contends on the same availability rows. How do you reduce contention while keeping correctness?
The PSP webhook for a capture arrives twice, and once out of order (refund before capture). How does your payment model stay consistent?
How would you extend the schema for loyalty tiers, multi-driver rentals, EV charging fees, and corporate accounts without a major rewrite?