System requirements
Functional:
- The user can park a vehicle: truck, car, van, motorcycle.
- Users can see available free lots of every type before starting parking.
- Disabled users can park their vehicles.
- The system should allocate the parking lots optimally: by price or by space.
- Parking lots may be either small, medium, or large.
- Parking has few entrances and exits and few floors.
- Users can buy tickets in the ticket machine by choosing the time interval, and transportation type.
Non-Functional:
- The system should be highly available to process the user's requests if though if one entrance is broken
- The system should process a user request with a response time lower than 100 ms.
- The system should be scalable to add additional entrances and exits for high user request frequency.
- The system should have the strong consistency
Capacity estimation
Let's say the customer would free all the parking lots every hour.
Car's information:
plate (10 bytes)
brand (30 bytes)
model (100 bytes)
Parking lot information:
parking lot id(8 bytes)
type: 1 byte
status: 1 byte(free,reserved, occupied)
for disabled: 1 byte
start Date:(8 bytes)
end Date: (8 bytes)
Let's count we have:
300 small, 200 medium and 100 large parking lots. The
truck may take 3 small or 2 medium parking lots if large ones aren't available.
It would generate 150 bytes * 600 = 100k * 24 = 2,5 Mbytes per day. 1 Gbytes for 1 year and 5 Gbytes for 5 years.
API design
park(apiKey,car plate, type of transportation, time interval) park a car if an available lot exists, otherwise, return the error.
unpark(apiKey, ticketId) the user would pay the parking time with a bank card or cash).
Database design
The primary data model for this system is two tables: one is for cars and the other is for parking lot occupied by the car.
It requires strong consistency. Once the parking lot is occupied or freed, it should be read by everyone.
RDBM such as Postgree, would fit the bill. It is also horizontally scalable and perfomant and it's strong consistent.
Car table:
car plate (10 bytes)
brand (30 bytes)
model (100 bytes)
Parking lot table:
parking lot id(8 bytes)
car plate (10 bytes)
type: 1 byte (small, medium or large)
status: 1 byte(free,reserved, occupied)
for disabled: 1 byte
start Date:(8 bytes)
end Date: (8 bytes)
We may choose to have some secondary indices for the table parking lot: status,type,start date,end date. For example, if user would want to park his car, the system would make search by status,type of parking lots.
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...
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.
Future improvements
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?