System requirements

The parking lot system will be a system that operates on multiple different parking lots, each parking lot will have a gantry that will open up to allow vehicles to enter and exit the carpark, and will charge vehicles based on the duration they are parked in the parking lot.

Functional:

• The system should keep track of the number of available lots in a parking lot, it will only allow vehicles to enter if there are available lots
• The system should be able to keep track of the number of lots of different types of vehicles, in this design we will consider motorcycles and cars only.
• The system should be able to charge the correct rates for different vehicles based on the duration of time they are parked, and based on the carpark in which they parked in (Some carparks would have higher rates than others). The system will only allow the vehicle to exit once they have paid their toll

Non-Functional:

• The system should be responsive,
• When a vehicle wants to exit a parking lot and a payment is made, the gantry should open up with little latency.
• When a vehicle requests to enter the parking lot and there are lots available, the gantry should open up with little latency
• The system should be reliable
• Since we are dealing with payments, we do not want the system to break down when payment is made, the fees could potentially be lost, or we could potentially double charge a vehicle, or we might even allow a vehicle to exit without paying the toll
• The system should also be handle a large number of requests during peak hours
• The system should be highly available
• There should be minimal downtime, this is to prevent vehicles from being stuck in a parking lot, or prevent vehicles from not being able to enter the parking lot

Capacity estimation

Lets say we are keeping track of 5,000 carparks Lets say for each carpark, 50,000 vehicles enter and exit each day.

Data to keep track of:

• Carpark info: carpark_id (20 bytes), number_of_car_lots (20 bytes), number_of_motorcycle_lots (20 bytes), number of available_car_lots (20 bytes), number of motorcycle lots (20 bytes), hourly_rate (10 bytes)
• Gantry info: carpark_id (20 bytes), gantry_id (20 bytes)
• Vehicle Entry: Vehicle_id (50 bytes), vehicle_type (20 bytes), entry_date_time (50 bytes), has_exit (4 bytes)

Storage Estimates:

• Total size carpark info: (20+20+20+10) * 5000 = 341KB
• Lets say for each carpark there are 4 gantries: (20 + 20) x 5000 x 4 = 20 KB
• Vehicle Entry Total: Lets say we keep the vehicle entry information for at most a year: (50 + 20 + 50 + 4) * 50,000 x 5,000 x 365 = 345 GB

Traffic Estimates:

• 50,000 vehicles to enter and exit a carpark per day
• Total vehicles = 50,000 * 5,000 = 250 million cars per day
• Assuming each car enters once and exits once
• 250 million * 2 write requests per day (entry and exit)

API design

• enter_carpark(vehicle_id, vehicle_type carpark_id, gantry_id, request_time, )
• Checks whether there are lots available for the vehicle type at a carpark
• If available, enter the vehicle information including the entry time, and open up the gantry, decrement the number of available lots in the carpark as well
• If not available, then dont open up the gantry
• exit_carpark(vehicle_id, vehicle_type carpark_id, gantry_id, request_time)
• Checks the database for the vehicle entry time
• Take the correct rate for the particular carpark, calculate the total fare, returns total fare
• pay_fare(fare, card, carpark_id, gantry_id)
• Assuming that the fare is paid by a card, the server will call an API that will process the payment, once successful open up the gantry

Database design

Data to keep track of:

• Carpark info: carpark_id (20 bytes), number_of_car_lots (20 bytes), number_of_motorcycle_lots (20 bytes), number of available_car_lots (20 bytes), number of motorcycle lots (20 bytes), hourly_rate (10 bytes)
• Gantry info: carpark_id (20 bytes), gantry_id (20 bytes)
• Vehicle Entry: Vehicle_id (50 bytes), vehicle_type (20 bytes), entry_date_time (50 bytes), has_exit (4 bytes)

The above has a lot of relations, for example when a car requests to enter or exit, you will have to search for relationship in the carpark DB, gantry DB, and vehicle_entry DB. In addition, the total storage needed is not very big, and we do not need to scale very much as well.

Hence I suggest an SQL database such as MySQL or PostgreSQL to keep track of the data

High-level design

We will have multiple gantries that act as clients that connect to the server that handles the entry and exit requests, the server will then connect to the SQL database

Request flows

• enter_carpark(vehicle_id, vehicle_type carpark_id, gantry_id, request_time, )
• Checks whether there are lots available for the vehicle type at a carpark
• If available, enter the vehicle information including the entry time, and open up the gantry, decrement the number of available lots in the carpark as well
• If not available, then dont open up the gantry
• exit_carpark(vehicle_id, vehicle_type carpark_id, gantry_id, request_time)
• Checks the database for the vehicle entry time
• Take the correct rate for the particular carpark, calculate the total fare, returns total fare
• pay_fare(fare, card, carpark_id, gantry_id)
• Assuming that the fare is paid by a card, the server will call an API that will process the payment, once successful open up the gantry

Detailed component design

We must be able to handle traffic during peak hour, when cars are exiting from their home carparks and entering office carparks. Hence we will most likely need multiple to handle the entry and exit requests.

Assuming during peak hours, there are 5000 requests made per second, and assuming each server can handle 500 requests per second, then we minimally need 10 servers during peak hours. We will most likely need backup servers in case one or more of them goes down. Hence I suggest 12 total severs.

We will definitely need a number of load balancers between the clients and servers. I suggest a round robin algorithm to distribute the load to different servers.

In addition, we will probably need a mechanism that clears entry records in the Vehicle_entry table that are there for more than a year. Instead of allocating more servers to do that, we can employ some of our currently existing servers to clear expired data from the database only during non-peak hours (10pm - 5am).

We would also want to have backup databases just in case our main DB goes down, we can have a server that is dedicated to duplicating data from our Vehicle_Entry Table in our main DB to our back up DBs. We can employ more servers to do this during off peak hours as well.

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

Failure scenarios/bottlenecks

There could be a situation where the gantry barriers have been tampered with, meaning vehicles can enter and exit the carpark through gantries that are broken without a request to the server. Of course, we will need to send someone there to fix the barrier, however, this means that our count of how many available lots in the carpark will be wrong. Meaning if a vehicle tries to enter a carpark through another gantry, the server might think there are lots available, when there are not. This could cause a jam in the carpark!

what we could possibly do is to employ sensors on each lot in a carpark, when a vehicle occupies a lot, it will trigger the server to decrement the available lot count, similarly when a car exits the lot, it will trigger the server to increment the available lot count

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?