Functional Features:
- User can reserve a parking spot.
- User pays for the reservation.
- User can park a car on the parking spot.
- User can leave before the reservation time expires.
- 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 Features:
- Scalability - our system should able to handle 1000 request over the world.
- Availability - system should has up time 99%.
- Consistency - should not be double booking of the same park spot.
Capacity estimation
Number of parking lots = 1000
Parking lot capacity = 200
Reservation requests per/day = 200 * 1000 = 200 000
Each reservation will add 128 byte in DB * 128 = 25.6MB of data per day.
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
- status
User table:
- user_id(key)
- info
Vechile table:
- vechile_id(key)
- user_id(foreign key)
- type
Spot table:
- spot_id(key)
- lot_id(foreign key)
Lot table:
- lot_id(key)
- capacity
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
healthcheck monitor - checks if all components of our system are available
cache - caching most use data to reduce latency reading from database
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 or bitmap approach to achieve time complexity O(1)
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.
In case of db crashes , would be better to use master-slave db approach with replication of db instances.
Future improvements
I believe that we use need to use CDN