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:

1. Client Apps makes quote request to get all available parking spots (not reserved, not held by other users) within the requested time period.
2. Client Apps makes hold request for the desired parking spot during the time period.
3. If still available, the hold will still be successful (will no longer show as available to other users).
4. 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.