Why parking lot is a classic LLD problem - Design It to Understand It

Design: Parking Lot System

Focus on core parking lot operations and spot management. Exclude payment gateway integration and mobile app UI.

Functional Requirements

FR1: Allow vehicles to enter and exit the parking lot

FR2: Track available parking spots by type (e.g., motorcycle, car, truck)

FR3: Assign parking spots to vehicles based on availability and vehicle type

FR4: Calculate parking fees based on duration

FR5: Support multiple floors or sections

FR6: Handle different vehicle sizes and spot sizes

Non-Functional Requirements

NFR1: Support up to 500 vehicles simultaneously

NFR2: Response time for spot assignment under 200ms

NFR3: System should be easy to extend for new vehicle or spot types

NFR4: Maintain consistency of spot availability in concurrent scenarios

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Vehicle and Parking Spot classes with attributes

Parking Lot manager to assign and release spots

Data store to keep track of spot availability

Fee calculator based on parking duration

User interface or API for entry and exit

Design Patterns

Factory pattern for creating vehicle and spot objects

Singleton pattern for Parking Lot manager to ensure single source of truth

Observer pattern to notify when spots become free

Strategy pattern for different fee calculation methods

Reference Architecture

  +-------------------+
  |   Entry Gate      |
  +---------+---------+
            |
            v
  +-------------------+       +-------------------+
  | Parking Lot Manager|<----->| Spot Availability  |
  +---------+---------+       +---------+---------+
            |                           |
            v                           v
  +-------------------+       +-------------------+
  | Vehicle Registry   |       | Fee Calculator    |
  +-------------------+       +-------------------+
            |
            v
  +-------------------+
  | Exit Gate         |
  +-------------------+

Components

Vehicle

Class/Interface

Represents different vehicle types with size and attributes

ParkingSpot

Class/Interface

Represents parking spots with size and availability status

ParkingLotManager

Singleton Class

Manages spot assignment, release, and overall parking lot state

SpotAvailabilityStore

In-memory data structure or database

Tracks which spots are free or occupied

FeeCalculator

Class with strategy pattern

Calculates parking fees based on vehicle type and duration

EntryGate and ExitGate

API endpoints or UI components

Handle vehicle entry and exit events

Request Flow

1. Vehicle arrives at Entry Gate and requests parking

2. ParkingLotManager checks SpotAvailabilityStore for suitable spot

3. Assigns spot and marks it occupied

4. Vehicle parks and entry time is recorded in Vehicle Registry

5. Upon exit, vehicle reports at Exit Gate

6. ParkingLotManager calculates fee using FeeCalculator based on entry and exit times

7. Spot is marked free in SpotAvailabilityStore

Database Schema

Entities: Vehicle (id, type, license_plate), ParkingSpot (id, type, floor, is_occupied), ParkingSession (id, vehicle_id, spot_id, entry_time, exit_time, fee), Relationships: Vehicle 1:N ParkingSession, ParkingSpot 1:N ParkingSession

Scaling Discussion

Bottlenecks

Single ParkingLotManager becomes a bottleneck with many concurrent requests

SpotAvailabilityStore may have contention with many updates

FeeCalculator may slow down if complex fee rules increase

Database can become slow with many ParkingSession records

Solutions

Partition parking lot into zones with separate managers to distribute load

Use distributed cache like Redis for SpotAvailabilityStore with atomic operations

Optimize FeeCalculator with caching or precomputed rates

Archive old ParkingSession records and index database for faster queries

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing classes and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing

Explain how vehicle and spot types affect design

Discuss concurrency and consistency in spot assignment

Highlight extensibility for new vehicle or spot types

Mention how fee calculation can vary and be modular

Show awareness of bottlenecks and scaling strategies

Practice

1. Why is the parking lot problem considered a classic example in low-level design (LLD)?

easy

A. Because it requires complex database queries for vehicle tracking

B. Because it is only about calculating parking fees

C. Because it focuses mainly on front-end user interface design

D. Because it involves managing different types of vehicles and parking spots with clear rules

Solution

1. Step 1: Understand the core challenge of parking lot design

   The problem requires managing different vehicle types (cars, bikes, trucks) and matching them to appropriate parking spots with specific rules.

2. Step 2: Identify why this fits LLD learning

   This involves object modeling, resource allocation, and rule enforcement, which are key LLD concepts.

3. Final Answer:

   Because it involves managing different types of vehicles and parking spots with clear rules -> Option D

4. Quick Check:

   Parking lot = resource allocation + object modeling [OK]

Hint: Focus on resource management and object rules in parking lot [OK]

Common Mistakes:

• Thinking it's mainly about UI or fees
• Confusing with database or front-end problems
• Ignoring the variety of vehicle and spot types

2. Which of the following is the correct way to represent a parking spot in a low-level design for a parking lot?

easy

A. function ParkingSpot() { return spotNumber + spotType; }

B. class ParkingSpot { int spotNumber; String spotType; boolean isOccupied; }

C. var ParkingSpot = [spotNumber, spotType, isOccupied];

D. ParkingSpot = spotNumber * spotType * isOccupied;

Solution

1. Step 1: Identify proper class structure for parking spot

   A parking spot should be modeled as a class with attributes like spot number, type, and occupancy status.

2. Step 2: Evaluate options for correctness

   class ParkingSpot { int spotNumber; String spotType; boolean isOccupied; } defines a class with clear attributes, suitable for LLD. Others are either functions, arrays, or invalid expressions.

3. Final Answer:

   class ParkingSpot { int spotNumber; String spotType; boolean isOccupied; } -> Option B

4. Quick Check:

   Class with attributes = correct parking spot model [OK]

Hint: Use classes with clear attributes for entities [OK]

Common Mistakes:

• Using arrays or functions instead of classes
• Mixing data types incorrectly
• Not including occupancy status

3. Given this simplified code snippet for a parking lot system, what will be the output?

class ParkingLot:
    def __init__(self):
        self.spots = {"car": 2, "bike": 1}
    def park_vehicle(self, vehicle_type):
        if self.spots.get(vehicle_type, 0) > 0:
            self.spots[vehicle_type] -= 1
            return "Parked"
        else:
            return "Full"

lot = ParkingLot()
print(lot.park_vehicle("car"))
print(lot.park_vehicle("car"))
print(lot.park_vehicle("car"))

medium

A. Parked
Parked
Full

B. Full
Full
Full

C. Parked
Full
Parked

D. Error due to missing bike spots

Solution

1. Step 1: Analyze initial spot counts and park_vehicle calls

   Initially, car spots = 2. First call parks a car, spots become 1. Second call parks another car, spots become 0. Third call finds no spots left.

2. Step 2: Determine output for each print statement

   First two prints output "Parked", third outputs "Full" because no spots remain.

3. Final Answer:

   Parked Parked Full -> Option A

4. Quick Check:

   Spot count decreases, last attempt fails [OK]

Hint: Track spot count decrement per park call [OK]

Common Mistakes:

• Assuming infinite spots
• Ignoring spot decrement
• Confusing vehicle types

4. In this parking lot design code, what is the bug causing incorrect spot allocation?

class ParkingLot:
    def __init__(self):
        self.spots = {"car": 2}
    def park_vehicle(self, vehicle_type):
        if self.spots[vehicle_type] > 0:
            self.spots[vehicle_type] = 0
            return "Parked"
        else:
            return "Full"

lot = ParkingLot()
print(lot.park_vehicle("car"))
print(lot.park_vehicle("car"))

medium

A. The park_vehicle method does not return any value

B. The spots dictionary is missing bike spots

C. The spot count is set to 0 instead of decrementing by 1

D. The vehicle_type key is misspelled

Solution

1. Step 1: Review spot count update logic

   The code sets spots[vehicle_type] = 0 directly instead of subtracting 1. With 2 initial car spots, first park sets it to 0 (should be 1).

2. Step 2: Understand impact on multiple park calls

   First park: "Parked", spots=0. Second park: "Full" but should succeed if decremented properly.

3. Final Answer:

   The spot count is set to 0 instead of decrementing by 1 -> Option C

4. Quick Check:

   Spot count update should decrement, not assign zero [OK]

Hint: Always decrement spot count, don't assign zero directly [OK]

Common Mistakes:

• Ignoring decrement logic
• Assuming spots dictionary must have all vehicle types
• Overlooking return statements

5. You are designing a parking lot system that must handle cars, bikes, and trucks with different spot sizes. Which design approach best supports scalability and maintainability?

hard

A. Create separate classes for each vehicle and spot type with a common interface for parking logic

B. Use a single class for all vehicles and spots with many if-else checks for types

C. Store all vehicles in a single list and assign spots randomly

D. Design only for cars first, then add bikes and trucks later without changing code

Solution

1. Step 1: Consider object-oriented design principles

   Using separate classes with a common interface allows clear modeling of different vehicle and spot types and their behaviors.

2. Step 2: Evaluate scalability and maintainability

   This approach supports adding new vehicle types easily and keeps code clean, unlike monolithic classes or random assignments.

3. Final Answer:

   Create separate classes for each vehicle and spot type with a common interface for parking logic -> Option A

4. Quick Check:

   Use OOP with interfaces for scalable parking lot design [OK]

Hint: Use separate classes and interfaces for each type [OK]

Common Mistakes:

• Using one class with many conditions
• Ignoring scalability needs
• Delaying design for other vehicle types