System requirements
Functional:
- Reservation:
- Users can reserve a parking spot through the system.
- Users can complete the reservation by making a payment.
- Parking Management:
- Allocate parking spots based on user reservations.
- Handle different vehicle types.
- Entry and Exit Management:
- Track vehicle entry and exit from the parking lot.
- 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?