Parking strategy pattern in LLD - System Design Exercise

Design: Parking Lot System with Strategy Pattern

Design focuses on the parking strategy pattern implementation and core parking operations. User authentication, payment processing, and physical hardware integration are out of scope.

Functional Requirements

FR1: Support multiple parking strategies (e.g., nearest spot, largest spot, electric vehicle spot).

FR2: Allow dynamic selection and switching of parking strategies at runtime.

FR3: Handle vehicle parking and unparking operations.

FR4: Track available and occupied parking spots.

FR5: Support different vehicle types (car, motorcycle, electric car).

Non-Functional Requirements

NFR1: System should handle up to 500 concurrent parking/unparking requests.

NFR2: Parking and unparking operations should complete within 200ms.

NFR3: System availability target is 99.9% uptime.

NFR4: Design should be extensible to add new parking strategies without major code changes.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

ParkingLot manager

ParkingSpot entity

Vehicle entity

Strategy interface and concrete strategy implementations

Spot availability tracker

Design Patterns

Strategy pattern for parking algorithms

Factory pattern to create strategy instances

Observer pattern to update spot availability

Singleton pattern for ParkingLot manager

Reference Architecture

  +-------------------+
  |   ParkingLot      |
  |  (Singleton)      |
  +---------+---------+
            |
            v
  +-------------------+        +-----------------------+
  | ParkingStrategy    |<-------| Concrete Strategies   |
  | (interface)       |        | - NearestSpotStrategy |
  +---------+---------+        | - LargestSpotStrategy |
            |                  | - ElectricSpotStrategy|
            v                  +-----------------------+
  +-------------------+
  | ParkingSpot       |
  +-------------------+
            ^
            |
  +-------------------+
  | Vehicle           |
  +-------------------+

Components

ParkingLot

Singleton class

Manages parking spots, vehicles, and delegates parking to selected strategy.

ParkingStrategy

Interface or abstract class

Defines method to find suitable parking spot for a vehicle.

NearestSpotStrategy

Concrete strategy class

Parks vehicle in the nearest available spot.

LargestSpotStrategy

Concrete strategy class

Parks vehicle in the largest available spot.

ElectricSpotStrategy

Concrete strategy class

Parks electric vehicles in spots with charging stations.

ParkingSpot

Entity class

Represents a parking spot with attributes like size, type, and availability.

Vehicle

Entity class

Represents a vehicle with type and size.

Request Flow

1. User requests to park a vehicle.

2. ParkingLot receives request and invokes current ParkingStrategy.

3. ParkingStrategy searches for suitable spot based on its algorithm.

4. If spot found, ParkingLot marks spot as occupied and assigns vehicle.

5. ParkingLot confirms parking success to user.

6. For unparking, ParkingLot frees the spot and updates availability.

Database Schema

Entities: - Vehicle(vehicle_id PK, type, size) - ParkingSpot(spot_id PK, size, type, is_occupied boolean) - ParkingAssignment(assignment_id PK, vehicle_id FK, spot_id FK, start_time, end_time nullable) Relationships: - One Vehicle can have zero or one active ParkingAssignment. - One ParkingSpot can have zero or one active ParkingAssignment. - ParkingAssignment links Vehicle and ParkingSpot with timestamps.

Scaling Discussion

Bottlenecks

ParkingLot manager becomes a bottleneck with many concurrent requests.

Searching for spots in large parking lots may be slow.

Updating spot availability under high concurrency can cause race conditions.

Solutions

Partition parking lot into zones with separate managers to reduce contention.

Use efficient data structures (e.g., priority queues, spatial indexes) for spot search.

Implement optimistic locking or distributed locks for spot updates.

Cache frequently accessed spot availability data in memory.

Interview Tips

Time: 10 minutes for requirements and clarifications, 15 minutes for design and patterns, 10 minutes for scaling and trade-offs, 10 minutes for Q&A.

Explain how strategy pattern enables flexible parking algorithms.

Discuss how to add new strategies without changing existing code.

Describe how concurrency and availability are handled.

Mention data model supporting parking assignments and spot tracking.

Highlight scalability approaches for large parking lots.