Parking strategy pattern in LLD - Deep Dive

Overview - Parking strategy pattern

What is it?

The Parking Strategy Pattern is a design approach used to manage how vehicles are parked in a parking lot system. It defines different ways or rules to allocate parking spaces efficiently based on vehicle type, availability, or priority. This pattern helps the system decide where and how to park vehicles without changing the core parking lot structure. It makes the parking system flexible and easy to extend with new parking rules.

Why it matters

Without a parking strategy pattern, a parking system would be rigid and hard to maintain. It would be difficult to add new parking rules or handle different vehicle types, leading to inefficient space use and frustrated users. This pattern solves the problem by separating parking rules from the parking lot itself, allowing smooth updates and better space management. It improves user experience and system scalability in real-world parking scenarios.

Where it fits

Before learning this, you should understand basic object-oriented design concepts like classes and interfaces. Knowing what design patterns are and why they help is useful. After this, you can explore other behavioral patterns like the State or Observer pattern to manage system behavior dynamically. This pattern fits in the journey of designing flexible, maintainable software systems.

Mental Model

Core Idea

A parking strategy pattern lets a system choose different parking rules independently from the parking lot, making parking flexible and easy to change.

Think of it like...

Imagine a parking lot with different attendants, each with their own way of parking cars—one parks by size, another by arrival time, and another by vehicle type. The parking lot just asks the attendant where to park next, without knowing their rules.

ParkingLot
  │
  ├─ uses ──> ParkingStrategy (interface)
  │             ├─ ParkBySize
  │             ├─ ParkByVehicleType
  │             └─ ParkByAvailability
  │
  └─ manages ──> ParkingSpaces

Flow:
Vehicle arrives → ParkingLot calls ParkingStrategy → Strategy decides spot → Vehicle parked

Build-Up - 7 Steps

1

Foundation

Understanding Parking Lot Basics

Concept: Learn what a parking lot system needs to do at the simplest level.

A parking lot has a fixed number of parking spaces. Vehicles arrive and leave. The system must track which spaces are free or occupied. Without any strategy, vehicles are parked in the first available spot.

Result

You can track parking spaces and park vehicles, but all vehicles are treated the same with no special rules.

Understanding the basic parking lot setup is essential before adding any complex parking rules or strategies.

2

Foundation

Introducing Vehicle Types and Constraints

Concept: Recognize that different vehicles may need different parking spaces or rules.

Vehicles can be cars, bikes, or trucks. Some spaces fit only certain vehicle types. For example, a bike space is smaller than a car space. The system must know vehicle types and match them to suitable spaces.

Result

The system can now reject parking a truck in a bike space, improving correctness.

Knowing vehicle types and space constraints sets the stage for flexible parking strategies.

3

Intermediate

Defining the Parking Strategy Interface

Concept: Create a common interface for all parking strategies to follow.

Define an interface with a method like 'findParkingSpot(vehicle, parkingLot)'. Different strategies will implement this method with their own rules. The parking lot will call this method to get the spot for a vehicle.

Result

The system can switch between different parking strategies without changing the parking lot code.

Separating the parking decision logic into a strategy interface enables flexibility and easier maintenance.

4

Intermediate

Implementing Common Parking Strategies

🤔Before reading on: do you think a 'ParkBySize' strategy would always find a spot faster than 'ParkByAvailability'? Commit to your answer.

Concept: Learn how different strategies apply different rules to find parking spots.

ParkBySize: Finds the smallest spot that fits the vehicle to save space. ParkByVehicleType: Finds spots reserved for the vehicle's type. ParkByAvailability: Finds the first free spot regardless of type. Each strategy implements the interface method differently.

Result

The parking lot can now use any strategy to park vehicles, changing behavior by swapping strategies.

Understanding how strategies differ helps you choose or design the best one for your needs.

5

Intermediate

Switching Strategies at Runtime

🤔Before reading on: do you think changing the parking strategy while the system runs requires stopping the parking lot? Commit to yes or no.

Concept: Learn how to change parking strategies dynamically without downtime.

The parking lot holds a reference to a ParkingStrategy object. At runtime, this reference can be replaced with a different strategy instance. This allows the system to adapt to changing conditions, like peak hours or special events.

Result

The parking lot can adapt its parking rules on the fly, improving flexibility and user experience.

Dynamic strategy switching is a powerful feature that supports real-world variability in parking needs.

6

Advanced

Handling Edge Cases and Failures

🤔Before reading on: do you think a parking strategy should always guarantee a spot? Commit to yes or no.

Concept: Explore how strategies handle no available spots or invalid vehicles.

Strategies must handle cases where no suitable spot exists. They can return null or throw exceptions. The parking lot must handle these gracefully, informing users or queuing vehicles. Strategies can also prioritize certain vehicles, like handicapped or VIPs.

Result

The system becomes robust, handling real-world complexities without crashing or confusing users.

Planning for failure and special cases is crucial for production-ready parking systems.

7

Expert

Optimizing Strategy Performance and Scalability

🤔Before reading on: do you think a simple linear search is efficient for large parking lots? Commit to yes or no.

Concept: Learn how to design strategies that scale well with large parking lots and many vehicles.

Naive strategies scan all spots linearly, which is slow for big lots. Advanced strategies use data structures like trees or hash maps to quickly find spots. Caching recent free spots or grouping by vehicle type improves speed. Strategies can also run asynchronously to avoid blocking the main system.

Result

Parking decisions happen quickly even in large, busy parking lots, improving throughput and user satisfaction.

Performance optimization in strategies is key for real-world systems with high demand and scale.

Under the Hood

The parking lot holds a reference to a strategy interface. When a vehicle arrives, it calls the strategy's method to find a spot. The strategy accesses parking space data and applies its rules to select a spot. This separation allows the parking lot to remain unchanged while strategies vary. Internally, strategies may use different algorithms and data structures to optimize spot selection.

Why designed this way?

This pattern was designed to separate concerns: the parking lot manages spaces, while strategies manage parking rules. This avoids hardcoding rules in the parking lot, making the system easier to extend and maintain. Alternatives like embedding rules directly would cause rigid, hard-to-change code. The strategy pattern supports open/closed principle, allowing new strategies without modifying existing code.

┌─────────────┐       ┌─────────────────────┐
│ ParkingLot  │──────▶│ ParkingStrategy (I)  │
│             │       │  ┌───────────────┐  │
│ - spaces    │       │  │ ParkBySize    │  │
│ - strategy  │       │  ├───────────────┤  │
└─────────────┘       │  │ ParkByVehicleType │  │
                      │  └───────────────┘  │
                      └─────────────────────┘

Flow:
Vehicle arrives → ParkingLot calls strategy.findSpot() → Strategy returns spot → Vehicle parked

Myth Busters - 4 Common Misconceptions

Quick: Does the parking strategy pattern mean the parking lot itself changes its structure for each strategy? Commit yes or no.

Common Belief: Many think the parking lot changes internally for each parking rule or strategy.

Reality: The parking lot structure stays the same; only the strategy for choosing spots changes independently.

Why it matters: Believing the lot changes leads to complex, duplicated code and harder maintenance.

Quick: Do you think all parking strategies must always find a spot for every vehicle? Commit yes or no.

Common Belief: Some believe strategies guarantee parking for every vehicle no matter what.

Reality: Strategies can fail to find spots if none are available; the system must handle this gracefully.

Why it matters: Assuming guaranteed parking causes bugs and poor user experience when the lot is full.

Quick: Is it true that switching parking strategies requires stopping the parking system? Commit yes or no.

Common Belief: People often think changing strategies needs system downtime or restarts.

Reality: Strategies can be swapped dynamically at runtime without stopping the system.

Why it matters: Knowing this enables flexible, adaptive systems that respond to changing conditions.

Quick: Do you think performance optimization is unnecessary for parking strategies in small lots? Commit yes or no.

Common Belief: Some believe optimization is only needed for huge systems, not small parking lots.

Reality: Even small lots benefit from efficient strategies, especially under heavy load or complex rules.

Why it matters: Ignoring performance early can cause scaling problems as the system grows.

Expert Zone

1

Some strategies combine multiple rules, like first filtering by vehicle type then by spot size, which requires careful ordering to avoid inefficiency.

2

Caching recent free spots can speed up parking decisions but risks stale data if not synchronized properly with real-time updates.

3

Dynamic strategy switching can cause inconsistent parking behavior if not coordinated with ongoing parking operations.

When NOT to use

Avoid using the parking strategy pattern when the parking rules are extremely simple and unlikely to change, as the added abstraction may complicate the design unnecessarily. For very small or fixed parking lots, a direct approach without strategies might be simpler. Alternatives include hardcoded rules or state machines if parking behavior depends heavily on system states.

Production Patterns

In real-world systems, parking strategy patterns are combined with event-driven updates to handle vehicle arrivals and departures asynchronously. Strategies often integrate with user priority systems (e.g., VIP, handicapped) and real-time sensors for spot availability. Cloud-based parking apps use this pattern to switch strategies based on time of day or demand, improving space utilization and customer satisfaction.

Connections

Strategy Design Pattern

The parking strategy pattern is a direct application of the Strategy design pattern in software engineering.

Understanding the general Strategy pattern helps grasp how parking strategies separate algorithms from the context, enabling flexible behavior.

Resource Allocation in Operating Systems

Both involve deciding how to assign limited resources (parking spots or CPU time) efficiently.

Learning parking strategies deepens understanding of resource scheduling and allocation principles used in OS design.

Traffic Flow Management

Parking strategies influence vehicle flow and congestion similar to how traffic management controls road usage.

Studying parking strategies offers insights into managing flow and optimizing space in physical and network traffic systems.

Common Pitfalls

#1 Hardcoding parking rules inside the parking lot class.

Wrong approach:

class ParkingLot {
parkVehicle(vehicle) {
// Always park in first free spot
for (spot of spots) {
if (spot.isFree()) {
spot.park(vehicle);
return;
}
}
}
}

Correct approach:

interface ParkingStrategy {
findSpot(vehicle, parkingLot);
}

class ParkingLot {
constructor(strategy) {
this.strategy = strategy;
}
parkVehicle(vehicle) {
const spot = this.strategy.findSpot(vehicle, this);
if (spot) spot.park(vehicle);
}
}

Root cause:

Not separating concerns leads to rigid code that is hard to extend or modify.

#2 Assuming a strategy always finds a spot and not handling failure.

Wrong approach:

const spot = strategy.findSpot(vehicle, lot);
spot.park(vehicle); // No check if spot is null

Correct approach:

const spot = strategy.findSpot(vehicle, lot);
if (spot) {
spot.park(vehicle);
} else {
notifyUser('No spots available');
}

Root cause:

Ignoring edge cases causes runtime errors and poor user experience.

#3 Switching strategies by creating new parking lot instances instead of swapping strategy objects.

Wrong approach:

const newLot = new ParkingLot(newStrategy); // Discards current state

Correct approach:

parkingLot.strategy = newStrategy; // Keeps current state, changes behavior

Root cause:

Misunderstanding dynamic strategy swapping leads to loss of system state and downtime.

Key Takeaways

The parking strategy pattern separates parking rules from the parking lot, enabling flexible and maintainable designs.

Different strategies can be swapped dynamically to adapt to changing parking needs without altering the core system.

Handling edge cases like no available spots is essential for robust parking systems.

Optimizing strategy performance matters for scalability, especially in large or busy parking lots.

Understanding this pattern connects to broader software design principles and real-world resource allocation problems.