Why parking lot is a classic LLD problem - Why This Architecture

Problem Statement

Managing a parking lot manually leads to confusion and errors when tracking available spots, vehicle types, and fees. Without a clear system, it becomes hard to handle different vehicle sizes, multiple entry and exit points, and billing accurately.

Solution

A parking lot system models real-world entities like vehicles, parking spots, and tickets as classes with clear responsibilities. It uses object-oriented design to handle different vehicle types, assign spots, track occupancy, and calculate fees automatically.

Architecture

Vehicle

→ParkingSpot

↓

Ticket

This diagram shows how Vehicle, ParkingSpot, and ParkingLot classes interact, along with Ticket and FeeCalculator components to manage parking and billing.

Trade-offs

✓ Pros

→

Clear separation of concerns makes the system easy to extend for new vehicle types or fee rules.

→

Object-oriented design models real-world entities intuitively, improving maintainability.

→

Supports multiple entry/exit points and dynamic spot assignment efficiently.

✗ Cons

→

Initial design complexity can be high for beginners due to multiple interacting classes.

→

Overhead of managing many objects may affect performance in very large parking lots.

→

Requires careful handling of concurrency if multiple users access the system simultaneously.

Use when building software to manage parking lots with multiple vehicle types, dynamic spot allocation, and billing, especially if the system must scale beyond a few dozen spots.

Avoid if the parking lot is very small (under 10 spots) or if manual tracking is sufficient and no software automation is needed.

Real World Examples

Uber

Uber uses parking lot management logic in their driver hubs to allocate parking spots dynamically based on vehicle type and availability.

Amazon

Amazon's warehouse parking systems use similar object-oriented designs to track employee and delivery vehicle parking efficiently.

LinkedIn

LinkedIn's office parking management software models vehicles and spots to optimize space usage and billing for reserved spots.

Code Example

The before code mixes all logic in one class and uses a simple list to track spots, which is hard to extend. The after code uses separate classes for Vehicle and ParkingSpot, encapsulating behavior and making it easier to add features like different spot types or vehicle sizes.

LLD

### Before: No clear design, everything in one function
class ParkingLot:
    def __init__(self, capacity):
        self.capacity = capacity
        self.spots = [None] * capacity

    def park(self, vehicle):
        for i in range(self.capacity):
            if self.spots[i] is None:
                self.spots[i] = vehicle
                return i
        return -1

### After: Object-oriented design with classes
class Vehicle:
    def __init__(self, license_plate, vehicle_type):
        self.license_plate = license_plate
        self.vehicle_type = vehicle_type

class ParkingSpot:
    def __init__(self, spot_id, spot_type):
        self.spot_id = spot_id
        self.spot_type = spot_type
        self.is_free = True
        self.vehicle = None

    def park_vehicle(self, vehicle):
        if self.is_free and self.spot_type == vehicle.vehicle_type:
            self.vehicle = vehicle
            self.is_free = False
            return True
        return False

    def remove_vehicle(self):
        self.vehicle = None
        self.is_free = True

class ParkingLot:
    def __init__(self, spots):
        self.spots = spots

    def park_vehicle(self, vehicle):
        for spot in self.spots:
            if spot.park_vehicle(vehicle):
                return spot.spot_id
        return -1

Alternatives

Procedural Design

Uses functions and data structures without encapsulating behavior in objects.

Use when: Choose when the system is very simple and does not require extensibility or complex interactions.

Database-Centric Design

Focuses on database tables and queries rather than object models.

Use when: Choose when the main concern is data storage and retrieval, and business logic is minimal.

Summary

Parking lot design models real-world entities to manage spot allocation and billing effectively.

Object-oriented design improves maintainability and extensibility for complex parking systems.

It is a classic beginner problem to learn how to break down requirements into interacting classes.

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