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:
check_capacity(lot_ID, vehicle_type, start_date_time, end_date_time) - checks the number of spare spots in the given parking lot and returns the 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) - verifies the payment token with the 3rd party payment mechanism, and finalizes the reservation.
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.
I think this builds a foundation for more feature development in the future, e.g., additional services, more vehicle and parking types (very large vehicles, buses and trucks, motorcycles and bicycles, charging stations).
Optimizations and availability improvement based on geographic locations would be a good area to invest further. For example, using Global Load Balancer so that clients get routed to the closest data center. Replicating databases between different geographic locations as a back up mechanism in case of a regional disaster.