Class identification (ParkingLot, Floor, Spot, Vehicle) in LLD - System Design Exercise

Design: Parking Lot Management System

Design the core classes and their relationships to model the parking lot, floors, spots, and vehicles. Out of scope: payment processing, user authentication, mobile app UI.

Functional Requirements

FR1: Allow vehicles to enter and find a parking spot

FR2: Support multiple floors with multiple spots per floor

FR3: Track which spots are occupied and which are free

FR4: Support different vehicle types (car, motorcycle, truck)

FR5: Allow vehicles to leave and free up spots

FR6: Provide a way to check availability of spots

Non-Functional Requirements

NFR1: System should handle up to 1000 vehicles simultaneously

NFR2: Spot allocation and release should be done within 200ms

NFR3: System should be designed for easy extension (e.g., new vehicle types)

NFR4: Maintain consistency of spot occupancy status

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

ParkingLot class to represent the entire parking structure

Floor class to represent each level in the parking lot

Spot class to represent individual parking spots

Vehicle class hierarchy for different vehicle types

Spot allocation and release logic

Design Patterns

Factory pattern for creating different vehicle types

Composite pattern for ParkingLot containing Floors and Spots

Strategy pattern for different spot allocation algorithms

Observer pattern to notify when spots become free or occupied

Reference Architecture

ParkingLot
  ├─ Floor 1
  │    ├─ Spot 1 (Car)
  │    ├─ Spot 2 (Motorcycle)
  │    └─ Spot 3 (Truck)
  ├─ Floor 2
  │    ├─ Spot 1 (Car)
  │    └─ Spot 2 (Car)
  └─ Floor N
       └─ Spot M

Vehicle
  ├─ Car
  ├─ Motorcycle
  └─ Truck

Components

ParkingLot

Class

Represents the entire parking lot containing multiple floors

Floor

Class

Represents a single floor in the parking lot containing multiple spots

Spot

Class

Represents an individual parking spot with a type and occupancy status

Vehicle

Abstract Class or Interface

Base class for different vehicle types

Car, Motorcycle, Truck

Classes inheriting Vehicle

Specific vehicle types with possible unique attributes

Request Flow

1. Vehicle arrives and requests a spot from ParkingLot

2. ParkingLot delegates request to Floors to find an available Spot matching vehicle type

3. Floor checks its Spots and returns an available Spot if any

4. ParkingLot assigns the Spot to the Vehicle and marks it occupied

5. When Vehicle leaves, ParkingLot marks the Spot as free

6. Availability queries check Floors and Spots for free spots

Database Schema

Entities: - ParkingLot (id, name, location) - Floor (id, parking_lot_id, floor_number) - Spot (id, floor_id, spot_type, is_occupied) - Vehicle (id, vehicle_type, license_plate) Relationships: - ParkingLot 1:N Floor - Floor 1:N Spot - Spot 0..1 Vehicle (occupied by one vehicle or none)

Scaling Discussion

Bottlenecks

Spot allocation latency increases with large number of floors and spots

Concurrency issues when multiple vehicles try to occupy the same spot

Tracking availability in real-time for large parking lots

Solutions

Use efficient data structures (e.g., priority queues) to quickly find free spots

Implement locking or atomic operations to prevent double allocation

Cache availability status and update asynchronously to reduce load

Interview Tips

Time: 10 minutes to clarify requirements and ask questions, 20 minutes to design classes and relationships, 10 minutes to discuss scaling and improvements, 5 minutes for summary

Explain class responsibilities clearly

Show understanding of relationships and associations

Discuss how to handle different vehicle and spot types

Mention concurrency and consistency considerations

Talk about extensibility for future features