Parking strategy pattern in LLD - Scalability & System Analysis

Scalability Analysis - Parking strategy pattern

Growth Table: Parking Strategy Pattern

Users / Vehicles	Parking Requests	Strategy Complexity	Storage & Data	Response Time
100 vehicles	~10 requests/min	Simple: single strategy, few rules	Small in-memory data	Fast, negligible delay
10,000 vehicles	~1,000 requests/min	Multiple strategies, moderate rules	Database for parking spots, vehicle info	Needs caching for speed
1,000,000 vehicles	~100,000 requests/min	Complex strategies, dynamic rules	Distributed DB, real-time updates	Load balancing, caching essential
100,000,000 vehicles	~10,000,000 requests/min	Highly complex, AI-assisted strategies	Sharded DB, geo-partitioning	Multi-region load balancing, CDN for static data

First Bottleneck

At small scale, the database becomes the first bottleneck because it handles all parking spot availability and vehicle data queries. As requests grow, the DB query load increases beyond a single instance's capacity.

Scaling Solutions

• Read Replicas: Use read replicas to distribute read queries for parking spot availability.
• Caching: Cache frequently accessed data like parking spot status to reduce DB load.
• Horizontal Scaling: Add more application servers behind a load balancer to handle increased requests.
• Sharding: Partition the database by geographic zones or parking lot IDs to reduce single DB load.
• Asynchronous Processing: Use message queues for non-critical updates to smooth spikes.
• Geo-Distributed Systems: Deploy services closer to users to reduce latency.

Back-of-Envelope Cost Analysis

• At 10,000 vehicles: ~1,000 requests/min = ~17 requests/sec.
• At 1,000,000 vehicles: ~100,000 requests/min = ~1,666 requests/sec.
• Storage: Each parking spot record ~1KB; 1M spots = ~1GB storage.
• Bandwidth: Assuming 1KB per request/response, 1,666 req/sec = ~1.6MB/s bandwidth.
• Network: 1 Gbps network can handle up to ~125MB/s, sufficient for this scale.

Interview Tip

Start by explaining the basic parking strategy pattern and its components. Then discuss how load grows with users and what breaks first. Propose clear, stepwise scaling solutions tied to bottlenecks. Use real numbers and simple analogies like parking lots filling up and needing more attendants or zones.

Self Check

Your database handles 1000 QPS. Traffic grows 10x to 10,000 QPS. What do you do first?

Answer: Add read replicas and implement caching to reduce direct DB load before scaling vertically or sharding.

Key Result

The database is the first bottleneck as parking requests grow; scaling requires caching, read replicas, and sharding by zones to maintain performance.

Practice

1. What is the main purpose of using the Parking Strategy Pattern in a parking lot system?

easy

A. To store vehicle details in a database

B. To manage payment processing for parking fees

C. To allow different algorithms for finding parking spots without changing the main system

D. To control the physical gates of the parking lot

Solution

1. Step 1: Understand the role of strategy pattern

   The strategy pattern lets you swap different algorithms easily without changing the main code.

2. Step 2: Apply this to parking system context

   In parking, it means you can change how spots are found without rewriting the whole system.

3. Final Answer:

   To allow different algorithms for finding parking spots without changing the main system -> Option C

4. Quick Check:

   Strategy pattern = flexible parking spot finding [OK]

Hint: Strategy pattern = flexible algorithm swapping [OK]

Common Mistakes:

• Confusing strategy pattern with data storage
• Thinking it controls hardware like gates
• Mixing it with payment processing logic

2. Which of the following is the correct way to define a parking strategy interface in a typical object-oriented design?

easy

A. class ParkingStrategy { findSpot(vehicle) {} }

B. function findSpot(vehicle) { return spot; }

C. var ParkingStrategy = new Object();

D. interface ParkingStrategy { findSpot(vehicle): Spot; }

Solution

1. Step 1: Identify interface syntax in OOP

   Interfaces define method signatures without implementation, e.g., interface ParkingStrategy { findSpot(vehicle): Spot; }.

2. Step 2: Compare options

   interface ParkingStrategy { findSpot(vehicle): Spot; } correctly uses interface with method signature. Others are class, function, or object, not interface.

3. Final Answer:

   interface ParkingStrategy { findSpot(vehicle): Spot; } -> Option D

4. Quick Check:

   Interface = method signature only [OK]

Hint: Interface defines method signatures only [OK]

Common Mistakes:

• Using class instead of interface for strategy
• Defining functions outside interface context
• Confusing object creation with interface definition

3. Given the following code snippet for two parking strategies, what will be the output when findSpot(vehicle) is called using NearestParkingStrategy?

class NearestParkingStrategy {
  findSpot(vehicle) {
    return "Nearest spot found";
  }
}
class RandomParkingStrategy {
  findSpot(vehicle) {
    return "Random spot found";
  }
}
const strategy = new NearestParkingStrategy();
console.log(strategy.findSpot('car'));

medium

A. "Nearest spot found"

B. "Random spot found"

C. undefined

D. Error: findSpot not defined

Solution

1. Step 1: Identify which strategy instance is used

   The code creates an instance of NearestParkingStrategy and calls findSpot.

2. Step 2: Check method output for that class

   NearestParkingStrategy.findSpot returns "Nearest spot found".

3. Final Answer:

   "Nearest spot found" -> Option A

4. Quick Check:

   Instance method output = "Nearest spot found" [OK]

Hint: Instance method output matches class used [OK]

Common Mistakes:

• Confusing which strategy instance is created
• Assuming random strategy is used
• Expecting undefined or error without reason

4. In the following code, what is the main issue that prevents the ParkingLot from using different parking strategies correctly?

class ParkingLot {
  constructor() {
    this.strategy = null;
  }
  setStrategy(strategy) {
    this.strategy = strategy;
  }
  park(vehicle) {
    return this.strategy.findSpot(vehicle);
  }
}
const lot = new ParkingLot();
lot.park('car');

medium

A. No strategy is set before calling park, causing an error

B. The park method should not call findSpot

C. The strategy property should be a list, not a single object

D. The constructor should initialize strategy with a default value

Solution

1. Step 1: Analyze object initialization and method calls

   The ParkingLot is created with strategy = null. No strategy is set before calling park.

2. Step 2: Understand consequence of null strategy

   Calling this.strategy.findSpot(vehicle) when strategy is null causes an error.

3. Final Answer:

   No strategy is set before calling park, causing an error -> Option A

4. Quick Check:

   Null strategy causes error on method call [OK]

Hint: Always set strategy before use [OK]

Common Mistakes:

• Thinking park method logic is wrong
• Assuming strategy should be a list
• Ignoring null initialization problem

5. You want to design a parking system that supports multiple vehicle types (car, bike, truck) and different parking strategies (nearest, random, reserved). Which design approach best uses the Parking Strategy Pattern to handle this complexity?

hard

A. Create separate parking lot classes for each vehicle type and hardcode the strategy inside each

B. Use a single ParkingLot class with a strategy interface; implement different strategies and select based on vehicle type at runtime

C. Store all vehicles in one list and assign spots randomly without strategy pattern

D. Use global variables to track vehicle types and apply strategies in procedural code

Solution

1. Step 1: Identify need for flexibility and scalability

   Supporting multiple vehicle types and strategies requires flexible design without code duplication.

2. Step 2: Apply strategy pattern with runtime selection

   Using one ParkingLot class with strategy interface allows swapping strategies dynamically based on vehicle type.

3. Step 3: Evaluate other options

   Create separate parking lot classes for each vehicle type and hardcode the strategy inside each duplicates code, C ignores strategy pattern, D uses poor global state management.

4. Final Answer:

   Use a single ParkingLot class with a strategy interface; implement different strategies and select based on vehicle type at runtime -> Option B

5. Quick Check:

   Strategy pattern + runtime selection = best design [OK]

Hint: Use one class + strategy interface + runtime choice [OK]

Common Mistakes:

• Duplicating classes per vehicle type
• Ignoring strategy pattern benefits
• Using global variables instead of OOP