Loading...
"Get number of spaces for vehicle type for given times"
GET /v1/spaces/available/
params: {
vehicle_type
start_time
end_time
}
returns: {
number_of_spaces
}
"Reserve a space for the given vehicle type"
POST /v1/spaces/reserve/
params: {
vehicle_type
licence_plate_number
payment_info (must be encrypted)
start_time
end_time
}
returns: {
space_number
confirmation_code
}
"Start a parking session when a user enters the lot (private)"
POST /v1/spaces/commit
params: {
license_plate_number
space_number
confirmation_code
}
"Cancel a current reservation"
DELETE /v1/spaces/reserve/
params: {
license_plate_number
}
returns: {
space_number
confirmation_code
}
"End a current parking session when a user leaves lot (private)"
DELETE /v1/spaces/reserve/
params: {
license_plate_number
}
returns: {
space_number
confirmation_code
}
If spaces can be reserved in hourly blocks, then determining if a space is available for a given hour should be easy.
We can use a relational database since consistency is a higher priority than performance.
We will have a reservation table, where the primary key is a composite of the space number and hour. Hour is an integer from 0 to 23 inclusive.
Reservation Table Schema:
When a reservation is made, N entries will be added to the Reservation Table, where N is the number of hours of the reservation.
When an hour elapses, all entries for that hour are cleared from the DB. When a vehicle exits early, all of its remaining reservation entries are cleared so another driver may reserve that spot.
This system has two APIs. A public API for users reserving or cancelling on a mobile device, and a private API for users interacting with a kiosk at the parking lot.
The public API allows for reserving spots and cancelling reservations. The private API allows starting and ending parking sessions. Online users may only interact with the public API while the kiosks interact with both.
An online user connects to a gateway, which is responsible for rate limiting, authentication, and load balancing (if needed).
The reservation server handles requests to read and update the reservation DB. The reservation DB stores reservations for the next 24 hours.
There is an hourly cron job to remove entries that pertained to the last hour from the Reservation DB.
One interesting problem is how to allocate vehicles efficiently in the parking lot. Some strategies could include prioritizing spaces near the exit, on lower floors, or away from other parked vehicles. Functionality could be added to calculate the optimal parking space for a given driver, either by enhancing the reservation server or adding a spot resolution service.
Since we expect the read/write ratio to be at least 10x, we can prioritize DB read performance and place a write-thru cache in front of the DB.
Most of the components of the system scale well: The API and Reservation servers are stateless, and the reservation DB could be sharded by hour or spot_id in theory. In fact, all of these should have multiple instances to maintain high availability in the case of a failure.