System requirements

Functional:

1. User can reserve a parking spot.
2. User pays for the reservation.
3. User can park a car on the parking spot.
4. User can leave before the reservation time expires.
5. There are three different parking spots - compact size, standard size, and with electric charger.
6. One common error case to handle is when a user makes a reservation, but fails to show up. In this case, we would charge for the first 24 hours.

Non-Functional:

1. Scalability. We are designing this for an international company who has 1000s of parking lots across nations.
2. Availability.
3. Consistency. Once a reservation is made, the parking spot must be available for the user. No double-booking.

There can be other considerations, e.g., indoor parking vs outdoor parking, additional services like car wash, and parking cars near the entrance to have a quick enter & exist experience. But for now, I'd like to focus on the requirements I listed above.

Capacity estimation

I assume:

• The company has operations in 10 countries.
• The company has 100 parking lots, on average, in one country.
• On average, each parking lot has a capacity of 200 cars. 70% standard cars. 20% compact cars. 10% electronic cars with chargers.
• 80% of users use it for short term parking, averaging 4 hours.
• 20% of users use it for long term parking, averaging 5 days.
• For each parking lot, there are on average 50 reservation requests per day.

Estimation:

• 10 * 100 = 1000 parking lots.
• For each day, this system will receive 50,000 reservation requests per day.
• Each reservation would mainly consists of:
• User ID (20 bytes)
• Car type (1 byte)
• Reservation start time (8 byte)
• Reservation end time (8 byte)
• Roughly totaling 40 bytes.
• Each day, we would add 400KB of data.
• In 2 years, it would add up to 292MB.

This estimate leads me to choose a relational database as the storage for reservations. The estimated size is within RDB's limits. RDB also gives strong consistency guarantee, which is suitable for a reservation system because avoiding inconsistency (e.g. double booking) is an important requirement. The response time requirement is not very hard. If reservation takes a couple of seconds (instead of milliseconds), that would be acceptable.

API design

APIs used by users:

check_capacity(lot_ID, vehicle_type, start_date_time, end_date_time): returns the number of open spots in the given parking lot. It also returns the price.

reserve_spot(user_ID, lot_ID, vehicle_type, start_date_time, end_date_time): it returns the reservation ID and the price.

pay(user_ID, reservation_ID)

APIs used by gate checking service at the parking lot:

vehicle_arrived(reservation_ID, date_time)

vehicle_left(reservation_ID, date_time)

Database design

Reservation table:

• reservation_ID (primary key)
• lot_ID (foreign key)
• user_ID (foreign key)
• start_time
• end_time
• vehicle_type (foreign key)
• payment_status (paid, unpaid, canceled)
• completion_status (to be completed, fulfilled, canceled)

Vehicle_Type table:

• vehicle_type_ID

Lot table:

• lot_ID (primary key)
• contact_info_ID (foreign key)
• Lot_Space ID (foreign key to Lot_Space table)
• capacities (foreign key to Lot_Capacity table)

Lot_Capacity table:

• lot_space ID (primary key)
• vehicle_type (foreign key to Vehicle_Type)
• number of space

Contact_Info table:

• contact_info_ID (primary key)
• contact_type
• contact_value

User table:

• user_ID (primary key)
• contact_info_ID (foreign key)
• vehicles (foreign key to Vehicle table)

Vehicle table:

• vehicle_ID (primary key)
• vehicle_type (foreign key to Vehicle_Type table)

Transaction table:

• transaction_ID (primary key)
• user_ID (foreign key)
• vehicle_ID (foreign key)
• check_in_date_time
• check_out_date_time

There can be enhancements, e.g., reviews for the parking lot, and reviews for the users. But for now, I will focus on the tables above.

High-level design

CDN caches static contents for high performance.

Rate Limiter protects the service from DOS attacks.

Load Balancer distributes requests to App Servers using weighted round robin algorithm.

As discussed above, RDB is used as the data store.

App Server uses Redis Cache for performance gain.

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?