System requirements

Functional:

• The system assigns slots to cars requesting to enter the parking lot. Then a car receives its slot and can enter the lot.
• The system keeps track of the number of cars in the lot at any given time. The system keeps count of each amount of different vehicle types
• a client makes a request to enter the parking lot or leave the parking lot.
• For each vehicle entering, entrance_time, vehicle_number, vehicle_type, and slot will be saved. When a car exits, the record of it will be erased.
• At the end of every day all records from the day will be erased
• A client will pay when exiting the lot. The payment will be based of the time a vehicle stayed in the lot.

Non-Functional:

• The system should prioritize consistency over availability since we do not want to admit multiple cars into the same slot.
• this is a write-heavy system

Capacity estimation

We assume the parking lot has 50 slots and that 500 cars pass in the parking lot every day.

500*30 = 15000 cars park in the parking lot every month.

However, we erase the information in the database every day when the parking lot closes so we do not need much scaling.

API design

"Assignment API" - using the "count microservice" it will be in charge of assigning slots to the different cars. The "count microservice" keeps count of how many cars are in the parking lot at a given time, and also it tracks how many vehicles of a certain type are in the parking lot. For example, when a motorcycle requests to enter the parking lot, the assignment API will reach the microservice, which will know if there is a slot for a motorcycle. If there is one, it will return the next available slot and will increment the count of motorcycles in the lot and total vehicles in the lot. Then, the new assigned slot will be stored with the vehicle's info in the DB and the API will return the response to the user.

"Cleanup API" - this API erases all the information stored from the passing day from the cache and the database once the parking lot closes for the day.

"Payment API" - The payment API is used when a vehicle wants to exit the lot. Using the vehicle's number, the Payment API will query the database, will find the proper entrance_time and will calculate the price to be payed.

Database design

a NoSQL DB that stores {vehicle_id: entrance_time, vehicle_type, assigned_slot, status}.

High-level design

Using a load balancer, the request from the client (enter/exit) will be directed to the right API. Each API will perform its role and will query the database to receive the info it needs.

Request flows

1. client wants to enter lot: the load balancer directs to the assignment API. The assignment API will use the count microservice to receive an open slot and will write it to the DB. An answer with the slot will be returned to the entering vehicle.
2. Client wants to exit: the load balancer directs to the payment API. The API queries the DB to get the info about the car (how long was it in the lot), calculates a price and returns to the client. Once the client payed he can exit the lot.
3. End of day: once the lot closes for the day, the cleanup API deletes all the info from the DB.

Detailed component design

database: we can use a NoSQL database because we don't have a need for highly structured data or complicated joins. NoSQL will allow high throughput.

Trade offs/Tech choices

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

Failure scenarios/bottlenecks

can have a bottleneck at the load balancer if many cars are trying to enter at once or when the lot is full

Future improvements

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