System requirements

Assumptions:

• Angled parking ensures ease of access.
• Any special need will only require 1.5 meters extra to car size.

Functional:

• The Parking Lot System should use angled parking to ensure easy access.
• The Parking Lot System should implement dynamic parking allocation, where spaces are allocated in real-time based on the size of the requestor and accessibility needs.
• The Parking Lot System should predict, based on historical metrics, the waiting time to get a parking space.
• The Parking Lot System should prioritize handicapped parking spots to allocate spaces close to entrances.
• The Parking Lot System should allow the following payment options: cash, credit/debit cards, mobile payment apps, and automated payment machines to accommodate different user preferences and streamline the payment process.
• The Parking Lot System should provide a location service to know where the car is parked.

Non-Functional:

• Low Latency: Customers do not want to wait for an assigned parking spot.
• The Parking Lot System should have a Surveillance System, Lighting, Access Control mechanism, Security Patrols, and Emergency Communication mechanisms.
• The Parking Lot System should provide on-site assistance, hotline support, or online chat to address any issue or inquiries promptly and efficiently.
• The Parking Lot System should provide clear, visible, and intuitive signage throughout the parking lot to guide drivers to their assigned parking spots, entrances, exits, and other facilities.
• Between car lines, the halls should have only one direction and be large enough to allow a single car of any size to transit.

Capacity estimation

Considering it will be a dynamic parking allocation, the capacity of the parking spot can be scalable to any size.

API design

1. bool::isFreeToPark GetParkingSpot ( carSize, accessibilityNeed, plates )
2. int::EstimatedTime GetWaitingTime ( carSize, accessibilityNeed )
3. bool::isFreeToGo PayParking ( plates )
4. void GetAssistance( plates )
5. Location whereIsMyCar ( plates )
6. guideMeToMyCar( plates )

Database design

To store the data, it is not required to have ACID. A columnar Database such as Cassandra will be used in order to keep a historical record that will be used for the prediction algorithm :

• Plates: Primary Key
• Car Size
• Assigned Spot
• Entrance timestamp
• Exit timestamp
• Customer Billing Information

High-level design

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

Customer payment information, such as debit card data, is not encrypted. This will represent a security hole.

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?