Design a Parking Lot

Step 1: Clarify requirements and scope

Confirm the scope before naming classes: multiple levels, three spot sizes (compact, regular, large), three vehicle types (motorcycle, car, van), and a ticket-based park/unpark flow with fee calculation. Ask: can a motorcycle use a regular or large spot if no compact spot is free? Is fee based on duration, spot size, or both? Is this single-process or does it need to survive a restart?

Step 2: Identify the core entities

The nouns in the problem map directly to classes: Vehicle (with a subtype: Motorcycle, Car, Van), ParkingSpot (with a size: Compact, Regular, Large), Level, ParkingLot, and Ticket. Resist adding entities the requirements did not ask for — no Driver class is needed unless the prompt mentions one.

Step 3: Assign responsibilities

ParkingLot owns the collection of Levels and coordinates cross-level spot search. Level owns its own list of ParkingSpots and knows how to find + reserve a free one. Ticket is a value object created on park and consumed on unpark — it should carry the entry time and the spot reference, not business logic. Vehicle knows its own size requirement; ParkingSpot knows whether a given vehicle fits.

Step 4: Define relationships

A ParkingLot has many Levels (composition). A Level has many ParkingSpots (composition). A ParkingSpot holds at most one Vehicle at a time (association, 0..1). A Ticket references exactly one ParkingSpot and one Vehicle. Model vehicle-to-spot sizing as a compatibility rule (motorcycle fits any spot; car needs regular or large; van needs large) rather than a rigid one-to-one mapping, since that rule is exactly what the "appropriately sized spots" requirement is testing.

Step 5: Design for extensibility

Two variation points are likely to be probed: spot/vehicle types and fee calculation. Use a strategy interface for fee calculation (duration-based, flat-rate, or size-based fee strategies can all implement the same interface) so a new pricing model does not touch ParkingLot or Level. For spot search, favor an interface like SpotAllocationStrategy so "nearest available spot" and "best-fit by size" can be swapped without changing the core park/unpark flow.

Step 6: Walk through the use cases

Trace park: a Car arrives, ParkingLot asks each Level for a free Regular-or-larger spot, the first Level with one reserves it and returns a Ticket stamped with entry time. Trace unpark: the Ticket is presented, the fee strategy computes cost from entry time to now and spot size, the spot is freed, and the Ticket is invalidated. Trace reporting: "available spots by type" is a read-only aggregate query across Levels — a good place to notice if your design requires locking during the count.

Step 7: Handle follow-ups

Electric vehicle charging spots: add a Charging capability (or a spot subtype) rather than a new vehicle type — a spot is either chargeable or not, independent of size, so keep it as a separate attribute/interface. Payment integration: keep it behind a PaymentProcessor interface invoked at unpark time, so swapping providers does not touch the parking logic.

Concurrency: two vehicles racing for the same spot is the concurrency question interviewers actually want — reserve the spot atomically (a lock per spot, or a compare-and-swap on spot status) before issuing the ticket, not after.

Related reading

• How to approach OOD interviews — the general framework this walkthrough follows.