System requirements

Functional:

1. Reservation:
   • Users can reserve a parking spot through the system.
   • Users can complete the reservation by making a payment.
2. Parking Management:
   • Allocate parking spots based on user reservations.
   • Handle different vehicle types.
3. Entry and Exit Management:
   • Track vehicle entry and exit from the parking lot.
4. Error Handling:
   • Address scenarios where users make reservations but don’t show up, possibly charging a fee for the first 24 hours.

Non-Functional:

Performance(latency, hight throughput), scalability(vertical/horizontal), availability, security, reliability, consistency etc

Capacity estimation

Number of parking lots = 1000

Parking lot capacity = 200

Reservation requests = 200 * 1000 = 200 000

API design

API used by user:

checkCapacity(lot_id, vechile_type, start_time, end_tine) [is_free, price] - checks if parking lot has a free spot and returns price

reserveSpot(user_id, lot_id, vechile_type, start_time, end_time) -

returns reservation_id and price. Also forwarded on 3d party payment system.

completeReservation(reservation_id, payment_token) - after payment we need to complete payment procedure

API used by parking lot:

vechile_arrived(reservation_id, time)

vechile_left(reservation_id, time)

Database design

Reservation table:

• Reservation_id(key)
• Spot_id(foreign key)
• User_id(foreign key)
• Payment_status
• Start_time
• End_time
• Stuts

User table:

• User_id(key)
• Contact_info

Vechile table:

• vechile_id(key)
• user_id(foreign key)
• type

Spot table:

• Spot_id(key)
• Lot_id(foreign key)

High-level design

Parking lot - notifies when car arrive or left

Client - user , that wants to get parking spot

Api gateway - mediator fro http requests

Reservation service - checks for empty place and update reservation in database

Payment service - 3d party for payments

Request flows

checkCapacity request handles by reservation service. It checks if we have an empty spot.

reserveSpot request - handles by reservation service. Adds. a new reservation in the system and redirect user for payment service.

completeReservation - after payment, user confirms that spot was paid by token.

vechile_arrived - notifies, when car arrived on parking lot.

vechile_left- notifies, when car left from parking lot.

Detailed component design

For reservation we can use first fit slot allocation or time-slot reservation with time intervals

Trade offs/Tech choices

Nosql db provides good horizontal scaling, but for us most important to have consistency, I mean we should prevent double booking of the same spot. SQL BD it is good choise , for instance PostgresSql

Failure scenarios/bottlenecks

Backend service are stateless. DB will be a bottleneck , it will difficult to scale. We can partitioned DB by parking id. Also we should use some heathcheck system.

Future improvements

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