System requirements

Functional:

• web and mobile
• Automated entry/exit
• Efficiently allocate spots
• Guide drivers to spots
• Payment through apps or kiosks
• Surveillance cameras, alarms
• Book spots in advance
• Feedback system
• Emergency response system
• Spots of different sizes
• User accounts

Non-Functional:

• scalability
• security
• performance
• usability

Capacity estimation

• Number of users per day = 185/4 = 46 users per day. Small number of users

API design

• User system
• Parking spot system
• Navigation system
• Payment system
• Security system
• Feedback system
• Entry/exit system

Database design

1. User database - stores user account information, such as user id, email, password, name, credit card info, license plate number
2. Parking spot database - stores which spots are taken, available or reserved
3. Entry/exit database - stores when a user came in and left. Would store user id and time in and out.
4. Payment database - stores due payments and past payments. Would link to a user id and store how much they paid, and when. The paid_at column would be null if they still owe a fee
5. Security database - store video footage
6. Feedback database - stores feedback from users. So it'd be a comment linked to a user id.

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...

graph TD

A(Web & Mobile Clients) --> B(Load Balancer)

B --> C(Web Servers)

C --> D(User System)

D --> E(User Database)

C --> F(Parking Lot System)

F --> G(Parking Database)

C --> H(Navigation System)

H --> I(Navigation Database)

C --> J(Payment System)

J --> K(Payment Database)

C --> L(Security System)

L --> M(Security Database)

C --> N(Feedback System)

N --> O(Feedback Database)

C --> P(Entry/Exit System)

P --> Q(Entry/Exit Database)

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...

sequenceDiagram

participant User

participant EntryExitSystem

participant NavigationSystem

participant ParkingSpotSystem

participant PaymentSystem

participant SpotSensor

User->>EntryExitSystem: User Enters Parking Lot

activate EntryExitSystem

EntryExitSystem-->>EntryExitSystem: Store Enter Event

EntryExitSystem-->>NavigationSystem: Request Route to Closest Spot

activate NavigationSystem

EntryExitSystem-->>NavigationSystem: User Car Size

NavigationSystem-->>EntryExitSystem: Closest Spot Route

deactivate NavigationSystem

EntryExitSystem-->>ParkingSpotSystem: Park at Closest Spot

activate ParkingSpotSystem

ParkingSpotSystem-->>SpotSensor: Spot Occupied

activate SpotSensor

SpotSensor-->>ParkingSpotSystem: Store Occupied Spot

deactivate SpotSensor

deactivate ParkingSpotSystem

EntryExitSystem-->>SpotSensor: User Leaves

activate SpotSensor

SpotSensor-->>ParkingSpotSystem: Spot Vacant

SpotSensor-->>PaymentSystem: Notify Payment

activate PaymentSystem

PaymentSystem-->>PaymentSystem: Record Fee

deactivate PaymentSystem

deactivate SpotSensor

deactivate EntryExitSystem

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...

Navigation System:

• Functionality: The Navigation System guides users to available parking spots based on their car size and real-time spot updates.
• Scalability: To scale efficiently, the Navigation System can use Graph data structures to represent parking lot layouts and implement pathfinding algorithms such as A search* for optimal route planning in complex parking structures.
• Algorithm: Using the A search algorithm* allows the Navigation System to consider factors like distance, car size compatibility, and real-time spot availability when determining the best route for users.
• Diagram:

graph LR

A(Navigation System) --> B(Graph Data Structure)

A --> C(Algorithm Module)

A --> D(Real-time Spot Updates)

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

• I have our backend do the path finding for our navigation system so the frontend has minimal processing it has to do

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

• We could have fault tolerance by using graceful degradation, so the software is still somewhat usable if we have an overload of requests
• We could have real time monitoring in place to catch errors and fix them before they become widespread

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?

• Maybe use a queue to process many parking spot requests