Class identification (ParkingLot, Floor, Spot, Vehicle) in LLD - Scalability & System Analysis

Scalability Analysis - Class identification (ParkingLot, Floor, Spot, Vehicle)

Growth Table: Parking Lot System

Scale	Number of Floors	Parking Spots	Vehicles Parked Concurrently	Requests per Second (Entry/Exit)
100 users	1-2 floors	50-100 spots	30-50 vehicles	10-20 requests/sec
10K users	5-10 floors	500-1000 spots	400-700 vehicles	200-500 requests/sec
1M users	20-50 floors	10,000-20,000 spots	8,000-15,000 vehicles	5,000-8,000 requests/sec
100M users	100+ floors (multiple lots)	1,000,000+ spots	800,000+ vehicles	500,000+ requests/sec

First Bottleneck

At small scale, the database is the first bottleneck. It stores data about floors, spots, and vehicles. As users increase, the database struggles to handle many read/write requests for parking spot availability and vehicle entry/exit.

At medium scale, the application server CPU and memory become bottlenecks due to processing many concurrent requests and managing state.

At large scale, network bandwidth and data partitioning become critical to handle massive traffic and data volume.

Scaling Solutions

• Database: Use read replicas to handle read-heavy traffic. Implement connection pooling to manage database connections efficiently.
• Caching: Cache frequently accessed data like available spots per floor to reduce database load.
• Application Servers: Horizontally scale by adding more servers behind a load balancer to distribute traffic.
• Data Partitioning: Shard the database by parking lot or floor to distribute data and reduce contention.
• Network: Use CDNs for static content (e.g., parking rules, maps) and optimize APIs for minimal data transfer.

Back-of-Envelope Cost Analysis

• At 1M users, expect ~5,000-8,000 requests/sec for entry/exit updates.
• Storage needed: Each vehicle record ~1KB, so 15,000 vehicles = ~15MB active data; historical logs add more.
• Bandwidth: Assuming 1KB per request, 8,000 req/sec = ~8MB/sec (~64Mbps), manageable with standard network setups.

Interview Tip

Start by defining system scale and key components (ParkingLot, Floor, Spot, Vehicle). Identify which component handles the most load. Discuss bottlenecks at each scale and propose targeted solutions. Use real numbers to justify your choices. Always mention trade-offs and how to monitor system health.

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 database load. Also, optimize queries and use connection pooling before considering more complex solutions.

Key Result

The database is the first bottleneck as user and request volume grow; scaling requires caching, read replicas, and horizontal application server scaling.

Practice

1. Which class in a parking system is responsible for managing multiple floors?

easy

A. ParkingLot

B. Floor

C. Spot

D. Vehicle

Solution

1. Step 1: Understand the role of ParkingLot

   The ParkingLot class represents the entire parking area and manages multiple floors within it.

2. Step 2: Compare with other classes

   Floor manages spots on a single level, Spot represents a single parking space, and Vehicle represents the car or bike.

3. Final Answer:

   ParkingLot -> Option A

4. Quick Check:

   ParkingLot manages floors = C [OK]

Hint: ParkingLot holds floors; floors hold spots [OK]

Common Mistakes:

• Confusing Floor as managing multiple floors
• Thinking Spot manages floors
• Assigning Vehicle to manage floors

2. Which of the following is the correct way to represent a parking spot in a class diagram?

easy

A. class Vehicle { int spotNumber; boolean isOccupied; }

B. class Spot { int spotNumber; boolean isOccupied; }

C. class Floor { int spotNumber; boolean isOccupied; }

D. class ParkingLot { int spotNumber; boolean isOccupied; }

Solution

1. Step 1: Identify the class representing a parking spot

   The Spot class should have attributes like spotNumber and isOccupied to represent a parking space.

2. Step 2: Check other classes for correctness

   Vehicle represents cars, Floor represents a level, and ParkingLot represents the whole area, so they should not have spotNumber or isOccupied attributes.

3. Final Answer:

   class Spot { int spotNumber; boolean isOccupied; } -> Option B

4. Quick Check:

   Spot class holds spot info = A [OK]

Hint: Spot class holds spot details like number and occupancy [OK]

Common Mistakes:

• Assigning spot attributes to Vehicle
• Putting spotNumber in Floor or ParkingLot
• Confusing class roles in diagram

3. Given the following code snippet, what will be the output?

class Vehicle {
  String licensePlate;
  Vehicle(String plate) { licensePlate = plate; }
}
class Spot {
  Vehicle parkedVehicle;
  boolean isOccupied() { return parkedVehicle != null; }
}
Spot spot = new Spot();
System.out.println(spot.isOccupied());

medium

A. true

B. Compilation error

C. null

D. false

Solution

1. Step 1: Analyze Spot initialization

   The Spot object is created but parkedVehicle is not assigned, so it defaults to null.

2. Step 2: Evaluate isOccupied method

   isOccupied returns true if parkedVehicle is not null; here it is null, so it returns false.

3. Final Answer:

   false -> Option D

4. Quick Check:

   parkedVehicle is null, so isOccupied() = false [OK]

Hint: Unassigned vehicle means spot is free (false) [OK]

Common Mistakes:

• Assuming default boolean is true
• Confusing null with false
• Expecting compilation error due to missing constructor

4. Identify the error in this class design snippet:

class Floor {
  List<Spot> spots;
  void addSpot(Spot s) {
    spots.add(s);
  }
}

medium

A. Spot class should be inside Floor class

B. Method addSpot should return boolean

C. spots list is not initialized before adding

D. Floor class should not have spots list

Solution

1. Step 1: Check initialization of spots list

   The spots list is declared but not initialized, so calling add on it will cause a runtime error.

2. Step 2: Validate other options

   Returning boolean is optional, Spot class can be separate, and Floor should have spots list to manage spots.

3. Final Answer:

   spots list is not initialized before adding -> Option C

4. Quick Check:

   Uninitialized list causes error = A [OK]

Hint: Always initialize lists before use [OK]

Common Mistakes:

• Ignoring list initialization
• Thinking method return type matters here
• Believing Spot must be nested class

5. You want to design a system where each Vehicle can only park in a Spot that matches its size (e.g., small, medium, large). Which class design change best supports this requirement?

hard

A. Add a size attribute to both Vehicle and Spot classes and check compatibility before parking

B. Add a size attribute only to Vehicle class and ignore Spot size

C. Add a size attribute only to Spot class and ignore Vehicle size

D. Remove size attributes and allow any Vehicle to park anywhere

Solution

1. Step 1: Understand size matching requirement

   Both Vehicle and Spot need size attributes to compare and ensure compatibility.

2. Step 2: Evaluate options

   Ignoring size in either class prevents proper matching; removing size ignores requirement.

3. Final Answer:

   Add a size attribute to both Vehicle and Spot classes and check compatibility before parking -> Option A

4. Quick Check:

   Size match needs attributes in both classes = B [OK]

Hint: Both Vehicle and Spot need size info to match [OK]

Common Mistakes:

• Adding size to only one class
• Ignoring size and allowing any parking
• Confusing attribute placement