System requirements

Functional:

• Users can reserve a parking spot.
• Users can park a vehicle in a parking spot.
• give the user a ticket when he enters the parking lot
• three different kinds of spots and vehicles: small, medium, and large.
• calculate fee when the user exists.

Non-Functional:

• scalability: handle large parking slots - 1000+ users in different parking slots using the same system
• performance: the system should handle 100 entries/exists per minute
• usability: the system should provide a user-friendly interface

Capacity estimation

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

assumptions:

• we have 3 different parking lots using the same system
• we have 200 parking spots.
• at peak time 100 vehicle enters per minute:
• avvaerge duration 2-4 hours

for that:

• data size for parking slot in one parking lot = 200*1000 = 20000 (this should fit in one machine)
• data for tickets : if we assume the min duration 2 hours then the max tickets in 24 hours is 200*12 = 2400 => data size : 2400*100 = 240000 (240kb)
• data for 10 years : 10 * 365* 240kB ~ 8MB

this leads to chose relational DB.

API design

Public Apis:

/reserve

params: vehicle_licence_plate, entry_time

returns: reservation_ID

/cancel_reservasion

params: vehicle_licence_plate, ticket_id

returns: boolean carRemoved

/payment

params: ticket_id, payment_method

returns: boolean is_paid

Internal Apis:

/allocate_spot

params: vehicle

returns: spot_id

/free_spot

params: spot_id

returns: boolean is_availabel

/calculate_fee

params : vehicle_licence_plae, ticket_id, exist_time

returns: double price

/login

params: user_id, password

return: boolean is_valid

Database design

DB TABELS:

Reservations Table:

• reservasion_id (primary key)
• parkingLot_id (foreign key)
• spot_id (foreign key)
• start_time (timestamp)

is_paid (boolean)

Parking Lot Table:

• parkingLot_id (primary key)
• rate (double)
• number_of_floors(int)
• number_of_spots(int)

Spots Table:

• spot_ID (primary key)
• vehicle_type (enum)
• is_available boolean

Vehicles Table:

• licence_plate (primary_key)
• user_id (foreign_key)
• vehicle_type (enum)

users table:

• user_id (primary key)
• user_first_name (string)
• user_last_name (string)
• address (string)
• email (string)

High-level design

You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...

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...

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...

Trade offs/Tech choices

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

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Future improvements

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