Requirements
Functional Requirements:
- Allow reservation of a parking spot.
- Process payment for the reservation.
- Enable parking of a car in the reserved spot.
- Support early departure before reservation time expires.
- Gate check-in/out.
- Handle no show.
- Designate accessibility spots and only allow vehicles whose passenger(s) need the spot to park there.
Non-Functional Requirements:
- Reliability.
- Strong consistency. When a reservation is made for a spot, it can not be made again until its available again.
- Low latency. Want to get vehicles in and out efficiently.
- High availability. Need to be able to check-in/out vehicles at all times.
- Scalability. Need to be able to handle reservations during peak hours/events.
API Design
Read
/quote
Request:
- start dayTime
- end dayTime
- accessibleSpotNeeded bool
Response:
- price
- array of parking spot numbers that are available
Write
/hold_spot
Request:
- reservation start dayTime
- reservation end dayTime
- userId
- parking spot number
Response:
- if spot no longer available, an error
- holdId: the id for the temporarily reserved spot
- spotNumber: the number of the spot that was reserved
/reserve_spot
Request:
- userId
- holdId
Response:
- if hold has timed out, an error
- reservationId
- spotNumber: the number of the spot that was reserved
- totalPrice: the price for the duration of the reservation
/arrive
Request:
- current dayTime
- userId
- reservationId
Response:
- success if dayTime is within reservation period and this person made the reservation and the reservation exists
- failure if !success and describe to user what went wrong
/leave
Request:
- current dayTime
- userId
- reservationId
Response:
- totalPriceDue
- fine if over reservation end dayTime?
/cancel
Request:
- userId
- reservationId
Response:
- success if user has a corresponding reservationId and it has been deleted
- failure if !success
???No show auditing/canceling of reservations???
High-Level Design
See block diagram!!!
Reserve Journey:
- Client Apps makes quote request to get all available parking spots (not reserved, not held by other users) within the requested time period.
- Client Apps makes hold request for the desired parking spot during the time period.
- If still available, the hold will still be successful (will no longer show as available to other users).
- Client can then pay for the held spot and reserve it.
Payments will be completed on using a third party provider/service, like Stripe.
All hold/reserve operations completed by the transaction/reservation services should update the db and invalidate the cache for that parking spot (making it available/unavailable for others to hold/reserve). Invalidating the cache should cause an update to be be made to the client/lot gate devices. Keeping the cache up to date with the write operations allows read operations (quote) to check the cache first, before querying the db. Caching what parking spots are available at given times should help with read/quote bursts of traffic.
If the cache is stale and a user tries to hold/reserve a spot that is no longer available, the client app should recognize that the error is for that reason, refetch the quote and update the client in a way that is intuitive for the user so that they can attempt to hold/reserve another spot.
The Relational DB is the source of truth for reservations.
Detailed Component Design
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.