Requirements


Functional Requirements:


  • Assign parking spots based on vehicle size, allowing motorcycles to park in small spots, cars in medium spots, and trucks in large spots, with the option to park in larger spots if needed.
  • Issue a ParkingTicket upon vehicle entry, which records the vehicle information, assigned parking spot, and entry timestamp.
  • Compute the parking fee upon vehicle exit based on the duration of stay and a configurable pricing strategy.
  • Handle scenarios where the parking lot is full by rejecting entry and displaying a lot-full indicator to the driver.
  • Support multiple floors in the parking lot, with each floor containing a mix of small, medium, and large parking spots.



Non-Functional Requirements:


  • List the key non-functional requirements (eg thread safety, extensibility, maintainability, etc.)...
  • Thread Safety :- The system must ensure strong consistence and linearizability during spot allocation process. We must use the distributed locks or optimistic concurrency control to prevent "double parking" (assigning the same spot to two vehicles) under high request volumes.
  • Extensibility:- The system should follow the Open-closed principle. it must be designed to support new vehicle type (Ex:- electric vehicle with charging needs) or new payment modes with (ex:- Crypto, NFC) without modifying the core parking logic"
  • Maintainability:- The system should aim for High Availability (99.9%). Even if the fee calculation service is down, the entry gates should function (fail-open/ fail-soft) to avoid traffic congestion. Additionally, the code should follow SOLID principles to ensure a low mean time to repair.
  • Scalability:- The system should handle a single small lot or a massive multi story complex with thousands of spots across different geographical locations.
  • Low Latency:- Entry and exit processing (gate opening) should happen in under 200ms to prevent vehicle queuing at physical entrances.
  • Reliability / Durability :- Parking transaction logs and ticket data must be persisted in db with ACID compliance to ensure no loss of revenue data.


Core Objects & Relationships

Based on the requirements and use cases, identify the main objects of the system and analyze how they interact and relate to each other...

class User{

id,

name,

email id,

phoneNo,

List vehicle List,

}


Abstract class Vehicle{

id,

licensePlate,

vehicleName,

vehicleType,

userId,

}


class MotorCycle extend vehicle{

}

class car extend vehicle{

}

class Truck extend vehicle{

}


user and vehicle will relate to each other with userId

one user can have multiple vehicle.


Abstract class ParkingSpot{

spotId,

isAvailable,

parkingType,

parkingStartTime,

parkingEndTime,

Vehicle vehicle,

}


class HandicappedSpot extends ParkingSpot{

}

class CompactSpot extends ParkingSpot{

}

class LargeSpot extends ParkingSpot{

}


A parking spot has a reference to the vehicle currently occupying it.


ParkingFloor{

Map>;


findAvailableSpot(vehicleType type);

}


ParkingLot(SingleTone){

ParkingFloor;


public ParkingTicket parkVehicle(Vehicle vehicle);

public Amount unparkVehicle(Vehicle vehicle);

}


ParkingTicket{

ParkingSpot parkingSpot;

}


Tranaction{

id,

transactionId,

amount,

transactionType,

ParkingTicket ticket;

}


parking and transaction table will relate to each other through with parkingID.


  1. Is A Relationship :- Vehicle Hierarchy - Car, truck and motorcycle is a relationship with Vehicle. They inherit common properties like license plate but may differ in sizes. Spot Hierarchy - HandicappedSpot, LargeSpot is-a relationship with parkingSpot. They inherit isAvailable status but have differ with physical dimensions.
  2. Has-A Relationship (Composition):- Composition indicates that child object cant exist without parent object. if the parent is destroyed , child also get destroyed automatically.
  • parkingLot and floors :- A parkingLot is composed of parkingFloors. if you delete the parkingLot from the system , the floors no longer exists.
  • parkingfloor and spots :- A parkingfloor is composed of parkingSpots.
  1. Has-A Relationship (Aggregation ):- Aggregations means the objects can exists independently.
  • ParkingSpot and vehicle - A parkingSpot has a vehicle. However, this is aggregation, not composition, because, the vehicle continues to exist in the system even after it leaves the parkingspot.
  • User and Vehicle:- A user has a vehilce. if the user account is deleted, the physical car still exists.




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

Explain design tradeoffs you considered. Check and explain whether your design adheres to SOLID principles. Explain how your design can handle changes in scale and whether it would be easy to extend with new functionalities. Identify areas for future improvement...

1. Adherence to SOLID Principles

Your design demonstrates several key SOLID concepts:

  • Single Responsibility Principle (SRP): You separated the physical space (ParkingSpot) from the session data (ParkingTicket) and the financial record (Transaction).
  • Open-Closed Principle (OCP): By using an abstract Vehicle class, the system is open for extension (e.g., adding ElectricCar or Ambulance) but closed for modification of the core parkVehicle logic.
  • Strategy Pattern (Liskov Substitution/Dependency Inversion): Using the PricingStrategy interface allows you to swap out HourlyPricing for FlatRatePricing without touching the ParkingTicket class.

2. Handling Concurrency (Thread Safety)

In a high-traffic lot, two cars might try to grab the same "last spot" at the same microsecond.

  • Approach: I used a synchronized block in the Singleton accessor and would implement a ReentrantLock at the ParkingFloor level when searching for spots.
  • Trade-off: While a global lock is simpler, locking at the Floor level is better for performance, as cars at Entrance A (Floor 1) won't block cars at Entrance B (Floor 2).

3. Scalability & Extensibility

  • Vertical Scaling: We can add more ParkingFloor objects to the ParkingLot list dynamically.
  • Horizontal Scaling: To support multiple geographical locations, we could transition the ParkingLot Singleton into a microservice where spot availability is tracked in a distributed cache like Redis to ensure low-latency lookups across different gates.

4. Design Trade-offs Considered

  • Centralized vs. Distributed Logic: I chose to let the ParkingFloor manage its own spots (Centralized). The alternative was letting ParkingSpot objects broadcast their own status. I chose the former to simplify the "find available spot" search, reducing the time complexity to $O(F \times S)$ where $F$ is floors and $S$ is spots per floor.
  • Database vs. In-Memory: For this OOD exercise, I used in-memory collections. However, for Reliability, I would back these with a relational database (ACID compliant) to ensure that if the system restarts, we don't "lose" the cars that are currently parked.

5. Future Improvements

  • Waitlist Management: If the lot is full, implement a PriorityQueue to manage a waiting list based on vehicle arrival time.
  • EV Charging Integration: Add a specialized ElectricSpot that monitors KWh usage and adds it to the final Transaction.
  • Dynamic Pricing: Implement a strategy that increases rates based on real-time occupancy levels (Demand-based pricing)