Design An Efficient Parking Lot System - System Design

System requirements

Functional:

List functional requirements for the system (Ask the chat bot for hints if stuck.)...

1. The Parking Lot system should be able to record a car's number on entrance and confirm the reservation

2. The system should be able notify a user upon successful reservation, entrance and an exit

3. During the exit, the system should identify the car's number and calculate the time it has spent on the parking lot. Based on that, it should notify a user about the payment and charge the user.

Non-Functional:

List non-functional requirements for the system...

1. Availability. The system should be highly reliable and error-prone because the parking service usually is working 24 hours a day. Once launched, the service should operate at 99.9999% of the time.

2. Security. The system should be highly secure. The user car's data and payment data should be encrypted.

3. Performance. The system should be highly responsive. The search for a parking lot should be quick taking no more than 1 or 2 seconds. The operation of reserving a parking lot should take no more than 1 second.

4. Scalability: The system should be able to handle increasing number of vehicles and users.

Capacity estimation

Estimate the scale of the system you are going to design...

Let's assume that the parking lot system operates in 200 cities. Each city on average has 20 parking buildings that uses our system. Each parking building is able to allocate around 200 vehicles, in which 180 are casual cars and 20 for trucks. Now, let's assume that the average time of keeping a car on a parking lot is 5 hours. Let's also assume that the drivers quickly fill all the allocated space. So, we may assume that there are around:

200 cities * 20 parking buildings * 200 vehicles = 800000 users that start interacting with our system daily

The number of operations for entering a parking or exiting would be 800000 requests per day.

The number of operations to search a parking lot and reserve it would make additional 1600000 requests.

Considering that 20% of the users would cancel their reservations and reserve another spot adds additional 320000 requests.

Overall, the system should be able to handle 800000 + 800000 + 1600000 + 320000 = 3520000 requests per day.

API design

Define what APIs are expected from the system...

1. APIs for entering and exiting the parking lot

/enter-parking/{buildingId}/{userId}

/exit-parking/{buildingId}/{userId}

2. APIs for reserving a spot in the parking lot

/reserve-parking/{buildingId}/{spotId}/{vehicleId}

/cancel-reservation/{buildingId}/{spotId}/{vehicleId}

Database design

Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...

DB Schemas:

User {

userId integer PK,

full_name varchar,

phone varchar,

password varchar

}

Vehicle {

vehicleId integer PK,

type "Truck" | "Car"

userId integer FK references User(userId)

}

Parking {

buildingId integer PK,

car_spots_count integer,

truck_spots_count integer

car_reserved_spots integer,

truck_reserved_spots integer

}

Spot {

spotId integer PK,

spotType "Truck" | "Car"

buildingId FK references Parking(buildingId)

}

High-level design

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

1. The client or a driver sends a request to a server. But before reaching a server, it goes to load balancer to deliver traffic uniformly among the servers.

2. Once the request reaches the server, rate limiting service checks whether particular user has not been sending already too many requests. In case if not, the server gets the user's request.

3. Based on the user request which can be entering, exiting, reserving a parking spot or cancelling, the server would handle the particular logic by sending the corresponding request to a database. The request can be also called as a transaction.

4. If the request is read-only like checking the available reservations, the server should also check the Redis cache first. Otherwise, it goes for the database

5. Database transaction is stored in the transaction queue and awaits its execution

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

Let's discuss the processing logic on the server side. So, once the reservation request is sent, the server would handle the data in the following way:

Each day is divided into 48 slots. Each slot correspond to 30 minutes.
start_date_time and end_date_time would be mapped into these slots. Slot 0 occupies time from 00:00 to 00:30 and so on. The time slots can be abstracted as an boolean array with length of 48.
In case of reservation approval, the boolean array would send corresponding slots to true meaning that they have been reserved.

Trade offs/Tech choices

1. The system will use Relational database instead of NoSQL solutions. RDBs are highly consistent, the database has very clear relationships between the tables. However, we will sacrifice the scalability because relational databases does not scale well horizontally.

Failure scenarios/bottlenecks

1. In case when users reserve a spot at the same time, there is a possibility of a race condition. To take care of that, we need to ensure that the database maintains a transaction queue based on first come first served basis.

Future improvements

There are many additional features that could be added at the existing system. For example, the parking lot may differentiate even more vehicle types. For the users that have not reserved in advance using the application, the gate may provide some interface to do the reservation in-person, just before entering a parking lot.