Requirements

Functional Requirements:

• The system should issue a parking ticket to a customer upon entry to an available spot. If the vehicle fits, the spot is available (upfill). No available spot of matching size on any floor means the vehicle is rejected at the entrance (lot full for that vehicle type)
• The system should keep track of spot availability per floor and the whole system
• Upfill-aware size availability - A motorcycle can fit into a car or truck spot but not the reverse
• The system should calculate the parking fee based on duration of the stay and vehicle type
• The system updates the spot count when vehicle processes payment
• Customers should be able to pay at an automated kiosk using cash or credit card
• The system should allow operators to add or remove parking floors and spots

Non-Functional Requirements:

• Concurrency - The system must safely handle simultaneous entries and exits. Two vehicles entering at the exact same time cannot be assigned the same parking spot
• Latency - Gate operations must execute in under 3 seconds to prevent traffic bottle necks
• Scalability - The architecture should support future expansion, handling multiple parking garage locations and tens of thousands of spots seamlessly
• Availability - The core exit and payment systems must be highly available (e.g., 99.99% uptime). System failures cannot trap vehicles inside the lot
• Extensibility - The system must support adding new vehicle types (e.g., oversized truck) and new fee strategies (e.g., weekend surcharge) without modifying existing core classes - new behavior is added, not edited into place
• Fail-safe: failure of mechanical parts should be tracked (e.g., if system fails, the system defaults to exits open state to prevent trapping vehicles)

Core Objects & Relationships

ParkingLot: top-level facade. Holds the floors, entry/exit gates and a PricingStrategy. Orchestrates parkVehicle() and exitVehicle()

ParkingFloor: one level; holds a list of ParkingSpots. Finds an available spot of a requested size

ParkingSpot: a single spot with a SpotType (SMALL/MEDIUM/LARGE) and an isAvailable flag. Can be occupied/released

Vehicle (abstract) -> Car, Motorcycle, Truck - each subclass knows its VehicleType

ParkingTicket: issued on entry; records the vehicle, spot and entry timestamp; used for fee calc at exit

Pricing Strategy (interface): HourlyStrategy, FlatRateStrategy implement fee calculation

Relationships & Behavior

Composition: ParkingLot owns ParkingFloor(s); ParkingFloor owns ParkingSpot(s). If the lot dies, floors/spots die with it

Inheritance: Car/Motorcycle/Truck extend abstract Vehicle

Association: ParkingTicket references a Vehicle and a ParkingSpot (doesn't own them)

Strategy: ParkingLot depends on the PricingStrategy interface, never a concrete rate class - so weekend pricing can be swapped in later without touching ParkingLot

APIs & Class Members

For each class, define the attributes (data) it will hold and the methods (functions) that operate on the attributes. Ensure they align with the object's responsibilities and adhere to the principle of encapsulation. Write your code in the code editor below.

Deep Dive

Single Responsibility Principle (SRP): Every class has one reason to change.

• ParkingSpot only manages its own state and invariant (canFit).
• ParkingFloor only handles collection search logic (findSpotForVehicle).
• ParkingTicket is purely a data container for the session.
• ParkingLot is the orchestrator that ties the subsystems together.

Open/Closed Principle (OCP): The system is open for extension but closed for modification. I built two major seams for this:

• Pricing: To add a WeekendPricingStrategy, I just create a new class implementing the interface. ParkingLot remains entirely untouched.
• Vehicles: To add an OversizedTruck, I create a subclass and add it to the VehicleSize rank map. The canFit and floor search logic never has to change.

Liskov Substitution Principle (LSP): Any subclass of Vehicle (Motorcycle, Car, Truck) can be passed into spot.park(vehicle) or floor.findSpotForVehicle() interchangeably without breaking the application logic.

Dependency Inversion Principle (DIP): ParkingLot depends on the PricingStrategy abstraction (interface), not the concrete HourlyPricingStrategy. This is injected via the constructor, which also makes the lot easily mockable for unit testing.

• The Current State (Honest Framing): "Right now, my enter() method uses an in-memory busy-wait flag to serialize entry. This successfully prevents double-booking if multiple gates are running on this exact machine, but it is a coarse, single-process lock."
• Step 1: Granular Locking: "To improve throughput on a single server, I would move from a global lot lock to per-floor locks. A vehicle searching for a spot on Floor 1 shouldn't block a vehicle entering Floor 3."
• Step 2: Concurrent Data Structures: "I would replace the standard in-memory Map for activeTickets with a highly concurrent structure (like a Redis hash or a ConcurrentHashMap in Java) so gates can read and write tickets simultaneously without a global mutex."
• Step 3: Distributed Architecture (The Senior Hop): "When this system scales to multiple servers across different gates, single-machine memory locks stop working. At that point, spot assignment must become an atomic datastore operation. I would use a Redis transaction or a relational database row lock (SELECT ... FOR UPDATE) on the parking spot to guarantee that two distributed gates cannot claim the same spot at the exact same millisecond."

Extensibility & Future Improvements

Wrap up the deep dive by throwing out a few one-liners that show you can anticipate product requirements before they are asked:

• EV Charging: "To support electric vehicles, I would create an ElectricSpot class that extends ParkingSpot with a ChargingStation object, and add a per-kWh surcharge to a new EVPricingStrategy."
• Reservations: "For reserved parking, I would introduce a Reservation class that pre-allocates a spot for a specific time window, with a background worker thread that expires stale or no-show reservations."
• Dynamic Pricing: "Because of the Strategy pattern, we could easily drop in a DynamicPricingStrategy that queries the isFull() capacity and automatically applies surge pricing when the lot hits 90% capacity."