System requirements
Functional:
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
Be able to direct cars to open parking spots
Track vehicle entry/exit, possible ticketing
Track capacity to decide whether or not to allow vehicles in or out
Allocate free space upon exit
Non-Functional:
List non-functional requirements for the system...
Low Latency - so customers aren't waiting for too long for directions or entry
Consistency over availability - cannot have customers in when there is no parking spot or led to wrong parking spot etc.
Find most efficient path to parking spot
Manage multiple entries and exits and don't have overlapping parking spot allocation
Capacity estimation
Estimate the scale of the system you are going to design...
On average each parking lot can have around ~60 parking spots per floor. ~5 floors in the parking lot. ~2 entries and ~2 exits.
Manage 60*5 = 3000 cars
At one time allocate + deallocate 4 parking spots concurrently maximum.
API design
Define what APIs are expected from the system...
isSpace(carSize) -> returns False or possible available parking spaces.
processEntry(carSize, licensePlate, parkingSpot) -> will ticket car. Allocate space in DB and claim the parking spot. Will call findPath(currentPoint, parkingSpot) - entry point will be current entry point
processExit(licensePlate, parkingSpot) -> deallocates parking spot in DB. Will call find path to find path to exit.
findBestSpace(carSize, availableSpaces, entryPoint) -> returns the most optimal parking spot, factoring in size of car and entry point for the closest parking spot
findPath(currentPoint, parkingSpot) -> finds most optimal path within parking lot. Either from parking spot or entry point to or from a specific parking spot. Must be able to avoid collisions with other moving vehicles.
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...
We can use a NoSQL Database as there is no need to a relational one. Because a parking lot has a static amount of spots, we can create entries for each parking spot and mimic real life parking. Put the vehicle information in each parking spot entry.
101 : {
available: False
vehicleSize: sedan
licensePlate: ladskjf
checkinTime: 12:00PM
}
Because we are prioritizing low latency for faster processing of customers, we can use DynamoDB.
Known for its low latency and scalability, ease of use for business owners.
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...
Because we will be dealing with maximum 4 requests at a time, we won't need to scale this system.
Once a car is at an entry point we will connect to the server via an HTTP request. Once the entry is processed, we will need to find a path which we will return to the client. The database will be updated to have a parking spot as unavailable. Once a car is at the exit, we process the exit, update the database and allow the car to leave.
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...
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...
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.
If we need to scale to have this system handle multiple parking lots, we could need to be able to store the layout for each parking lot, and scale the findPath api more heavily.
Because we are prioritizing consistency over availability, when this system deals with more parkinglots or larger parkinglots with more entries/exits, we would need to figure out how to make information more readily and accurately avaiailable. additionally a possible issue is the lengthened latency due to the preference of consistency. We would have a long line of real traffic waiting for a response.
Future improvements
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?