List functional requirements for the system (Ask the chat bot for hints if stuck.)...
List non-functional requirements for the system...
Estimate the scale of the system you are going to design...
Total number of parking spots/parking lot = 200
Short term parking spots = 333
Long term = 167
Max number of reservations for short term/day = 18
Max Long term reservations = 167 per day
Total number of reservations = 333 * 18 + 167 = 600 + 200 = 800
Total for all parking lots = 800 * 500 = 400,000 records
Each reservation record {
VIN - 20bytes
start time - 8 bytes
end time - 8 bytes
userId - 20bytes
status - 2 bytes
billId - 8bytes
} = 60 bytes
Store data = 400000 * 60 = 24000000 = 24 MB / day
24MB * 365 = 8760 MB = 9 GB
Define what APIs are expected from the system...
Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...
Reservation{
resourceId - primaryKey
lotId - fk for parkingLot
parkingType - Enum - shortTerm or LongTerm
startTime
endTime
userId - fk for User table
reservationNumber
status
}
User{
resourceId - primaryKey
firstName
lastName
userId
vehicleId [] - fk vehicle table
phoneNumber
}
ParkingLot {
resourceId - primaryKey
parkingLotId
shortTermCount
longTermCount
addressLine1
city
state
zip
}
Vehicle {
resourceId - primaryKey
vehicleType
make
model
licensePlate
}
You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...
At a high level, the system will have the client browser making request for various actions like - check availability of spots, make reservation and cancel reservation from a browser. The request will go to Load Balancer which will redirect it to API Gateway. API gateway will validate that the API is allowed to access the resource and forward the request to an instance of available Application Server. There will be at least 3 different services running for the APIs mentioned above and each service will have multiple instances depending upon availability and needs. The application servers will have scalability defined during deployment with min and max instances.
App Servers will have connection to Redis server where the ParkingLot info will be cached. It will make call to DB directly for making reservation and cancelling reservation. Reservation info and User info may not be needed to be cached.
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...
Diagram created
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...
The makeReservation API will get information about parkingLot by parkingLotId that is passed. This should have the number of short term and long term parking spots in the parking lot. After that the API will query DB by parkingLotId, parkingType and reservationStartTime is less than user's reservationStart time or reservation end time is greater than user's start time. This will give number of spots that are occupied duting that time. If number of spots available is < total spots, return available spots. If not, return 0.
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?