System requirements
Functional:
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
- User is aware of their parking needs and will choose either short term or long term parking
- There will be multiple parking lots through out the country and each parking lot will have fixed number of short term and long term parking spots.
- When user makes a reservation they will specify the maximum number of hours or days that they will be parking the vehicle.
- For short term parking, user will choose the starting time and end time up to 4 hours.
- For long term parking, the user will choose number of days irrespective of the time they park.
- If it is more than 4 hours, user will have to park in long term parking lot.
- User will decide which parking spot to use for its parking needs
- User will be able to cancel the parking reservation 24hours before the start time at no additional cost. Within 24 hours, user will have to pay partial amount.
- The system will focus only on checking if parking spot is available or not, it will not look into billing aspect at this time.
- The system will open up the parking spot when the cancellation is made irrespective of time of cancellation.
- After the reservation is made, the system will send confirmation notification.
- Technical details of notification are out of scope for this solution.
Non-Functional:
List non-functional requirements for the system...
- There are 500 parking lots with each parking lot having average capacity of 200 vehicles.
- Let us assume that the ratio of short term to long term parking is 2:1
- The system should be scalable, but it won't scale to millions or billions of transactions or data. Scalability is a low priority for this problem.
- System should have response time of few ms.
- System should have 99.99% availability to make reservation and cancel reservation
- System should have strong consistency for data accuracy
- In order to make system reliable, we should have data replication strategy.
- During cancellation, a system will be needed to authenticate the user that is canceling the reservation
Capacity estimation
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
API design
Define what APIs are expected from the system...
- HTTP POST boolean checkAvailability(parkingType, parkingLotId) - This API will be used to check if the desired parking lot has spots available for the parking type that the user needs.
- HTTP POST String makeReservation(parkingLotId, parkingType, startTime, endTime, userId) - This API will be a transactional API that will check if spot is available before inserting data in table and then insert record in table. If no spot available, it will return 404 reposnse code, otherwise it will return reservationNumber,
- HTTP POST void cancelReservation(reservationNumber, userId) - This API will verify that the reservation belongs to the user passed in request. If not it will return an error code and response code of 400. It will verify that the reservation has not expired. If yes, it will return an error code and response code of 400. If reservation is being cancelled 24 hours in advance, it will mark the reservation as cancelled return response code of 200. If the reservation is within 24 hours, it will return an error code and response code of 400.
Database design
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
}
High-level design
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.
Request flows
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
Detailed component design
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.
Trade offs/Tech choices
Explain any trade offs you have made and why you made certain tech choices...
Failure scenarios/bottlenecks
Try to discuss as many failure scenarios/bottlenecks as possible.
Future improvements
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?