Loading...
Reservation of Parking Spot: Users should be able to reserve their parking spot in advance
Payment Processing: User's need to be able to pay for their parking reservation
Early Exit: User's should be able to leave the parking before their reservation expire
Parking Expiration: User's should have additional fees added to their payment if they leave the parking after their reservation expires
No Show Policy: System need to able to handle charges if the customer doesn't show up
Consistency: Needs to prevent double-booking
Availability: System must be available for process over 99.999% of time
Scalability: The system should be able to handle pacrking reservations across different locations and handle a large number of parking lot and requets.
Given the situation where we have a parking lot with 250 available spot and we expect to have occupancy rate of 80%, and that on average each car use the parking space for at least an hour.
Additionally, the parking pass is divided accross Car types
60% --> Standard Cars
20% --> Compact Cars
20% --> Electric Cars
We need to handle 200 traffic requests at any given time. If the system is being used in 3 parking lot with the same capacity we'll account for 600 request/hour
14400 requests/day
432000 requests/month
And around 5.4 million requests/year
Each Reservation request include
Current TimeStamp ------> 13 bytes
Car Type ------> 1 byte
Reservation ID ------> 8 Byte
Reservation EndTime ------> 8 Byte
For a total of 30 bytes per request
162 MB per year
The API Needs to be control user's interaction and the activity controled by the gate control service
Gate Control Service:
Operation Controlled
-Vehicle Entered(ReservationID, CarType, CurrentTimeStamp, ReservationEndTime)
/api/vehicle/start
-Vehicle Leaving(ReservationID, ReservationEndTime, CurrentTimeSTAMP)
/api/vehicle/leave
User Contol Services:
Reservation (This is endpoint allow user's to book a reservation for their parking spot)
api/reservation/booking [reservationID, LotID, CarType]
Payment (This endpoint process payment gateway for reservation booking)
api/service/payment [reservationID, reservationTime(number of hours booked), customer_name, paymentInformation]
CheckCapacity (This endpoint check the capacity of the parking lot and will be used in the reservation process)
api/service/capacity [LotID, startTime, Endtime, CarType]
CancelReservation (This endpoint will allow user's to cancel their previous registration)
api/reservation/cancel
[UserID, PaymentInformation, LotID, CarType]
the Database show incorporate these tables:
Users, Reservation, Transaction, Parking_Lot
User
UserID ---> INT [PK]
Name ---> VARCHAR
Payment Information ---> VARCHAR
Reservation
ReservationID ---> INT [PK]
UserID ---> INT [FK]
TransactionID ---> INT [FK]
ParkingID ---> INT [FK]
TimeBooked ---> INT
LotID ---> ENUM
CarType ---> ENUM
STATUS ---> ENUM
Payment_Status ---> ENUM
Parking_Lot
ParkingID ---> INT [PK]
Capacity ---> INT
Transaction
TransactionID ---> INT[PK]
UserID ---> INT[FK]
start_time
end_time
Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...
Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...
Explain any trade offs you have made and why you made certain tech choices...
Try to discuss as many failure scenarios/bottlenecks as possible.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?