System requirements

Functional:

List functional requirements for the system (Ask the chat bot for hints if stuck.)...

1. reserve a spot and some kind of ticket or receipt
2. pay for sport
3. different types of parking, sizes, handicap, etc

Non-Functional:

List non-functional requirements for the system...

1. scalability - needs to have high consistency - no race conditions - no two people should be able to reserve the same spot at the same time

• Use a distributed database for large parking lots.
• Use a load balancer for incoming requests.
• Support for horizontal scaling (adding more floors).

Capacity estimation

Estimate the scale of the system you are going to design...

parking garages come in different sizes, the largest ones usually have multiple floors.

at most can fit from 100 - 2000 cars per garage

probably at most the high range will be less than a million cars

API design

Define what APIs are expected from the system...

/reserve

params: garage_id, start_time, end_time

returns: (spot_id, reservation_id) -> tuple


/payment

params: reservation_id

note: likely using an existing third party API to handle (Stripe, Square, etc)


/cancel

params: reservation_id

/calculate_payment

params: reservation_id


/freespots

params: garage_id, vehicle_type, time


/alllocate_spot

params: garage_id, vehicle_type, time


/create_account

params: email, password, first_name, last_name,

note add third party SSO (Google, Facebook)


/login

params: email, password

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

ParkingSpots: Track spot ID, type, availability, assigned vehicle.

Vehicles: Store vehicle details and parking history.

Payments: Store payment info (amount, time).

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

Request Flows

1. Vehicle Entry

1. Client Action:
   • Driver approaches the entry gate. License plate is scanned, or the driver enters vehicle details into a website.
2. Request Flow:
   • Step 1: Gate system sends a request to the backend server to check for available spots for the vehicle type.
   • Step 2: Parking Spot Manager queries the backend server for available spots.
   • Step 3: If a spot is available:
     • Assigns the spot to the vehicle.
     • Updates the database to mark the spot as occupied.
     • Opens the entry gate.
   • Step 4: System sends confirmation (e.g., spot number and directions) to the client.
3. Outputs:
   • Spot assigned.
   • Entry gate opens.

2. Spot Search and Parking

1. Client Action:
   • Driver uses the kiosk/mobile app to find their assigned spot.
2. Request Flow:
   • Step 1: Spot assignment details are fetched from the backend server
   • Step 2: Driver is directed to the spot using IoT Sensors or a map provided by the system.
3. Outputs:
   • Driver parks the vehicle.

3. Vehicle Exit

1. Client Action:
   • Driver requests exit by entering their ticket/license plate at the exit kiosk or through the app.
2. Request Flow:
   • Step 1: Exit kiosk sends a request to the Vehicle Manager to retrieve entry time.
   • Step 2: Vehicle Manager calculates the duration of the stay.
   • Step 3: Parking fee is calculated using the Payment System.
   • Step 4: Driver pays the fee via the app, kiosk, or card reader integrated with a Payment Gateway.
   • Step 5: After payment confirmation, the Parking Spot Manager releases the spot and updates the database.
   • Step 6: Exit gate opens.
3. Outputs:
   • Parking fee paid.
   • Exit gate opens.

4. Spot Availability Check

1. Client Action:
   • User queries spot availability via the mobile app or kiosk.
2. Request Flow:
   • Step 1: Client request is routed to the Parking Spot Manager.
   • Step 2: Spot Manager queries the Parking Spot Database for current availability.
   • Step 3: Available spots are returned to the client.
3. Outputs:
   • Spot availability displayed to the user.

5. Payment Processing

1. Client Action:
   • Driver initiates payment via kiosk, app, or automatic deduction.
2. Request Flow:
   • Step 1: Payment request is sent to the Payment System.
   • Step 2: Payment System calculates the amount based on the duration retrieved from the Vehicle Manager.
   • Step 3: Payment request is sent to the external Payment Gateway.
   • Step 4: Upon success, the payment details are logged in the Payment Logs database.
   • Step 5: Confirmation is sent to the client.
3. Outputs:
   • Payment receipt provided to the user.

6. Notifications

1. Client Action:
   • User receives alerts for upcoming charges, spot assignments, or receipts.
2. Request Flow:
   • Step 1: The system generates an event (e.g., parking time nearing expiration).
   • Step 2: Event is processed by the Notification System.
   • Step 3: Notification is sent via SMS, email, or app push notification.
3. Outputs:
   • User receives timely notifications.

Optimized Architecture for Request Flow

1. Asynchronous Operations:
   • Use message queues (e.g., Kafka, RabbitMQ) for time-consuming tasks like spot updates or payment confirmation.
   • This reduces gate delays.
2. Caching:
   • Cache frequently accessed data like spot availability using Redis or Memcached for faster response times.
3. Load Balancers:
   • Distribute incoming requests across multiple servers to handle high traffic.
4. Monitoring:
   • Implement logging and monitoring tools (e.g., ELK Stack, Prometheus) to track request flows and detect bottlenecks.

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

strong consistency is prioritized vs speed. don't want incorrect spots allocated

• Real-world considerations: shard location based on zip codes.
  • Strong consistency ensures correctness but may reduce speed.
  • Sharding based on location minimizes irrelevant locking.

Failure scenarios/bottlenecks

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

Database Outage:

• If the database goes down, the system won’t track parking spot availability, vehicle entry/exit times, or payments.
• Mitigation: Use database replication and caching for redundancy. Implement retries for failed operations.

Payment Gateway Failure:

• If the payment system is unavailable, customers may not be able to pay and exit.
• Mitigation: Allow offline payments or deferred payment processing.

Hardware Failures:

• Sensors or gates may malfunction, causing delays in vehicle entry/exit.
• Mitigation: Regular maintenance and failover mechanisms like manual ticketing.

Server Downtime:

• Application servers may crash under heavy load.
• Mitigation: Use load balancing and scalable infrastructure (e.g., cloud services).

Bottlenecks

1. Entry/Exit Points

• Slow Processing:
  • If spot assignment or payment takes too long, it can cause a queue.
  • Mitigation: Use automated kiosks and ensure the process is fast.
• Limited Gates:
  • Few entry/exit gates lead to congestion.
  • Mitigation: Add more gates and distribute traffic intelligently.

2. Centralized Systems

• Single Point of Failure:
  • A central server managing spot availability or payments can become overwhelmed.
  • Mitigation: Use distributed systems and regional processing nodes.

3. Database Locks

• Concurrent Updates:
  • Multiple vehicles attempting to update the same spot status can lead to deadlocks.
  • Mitigation: Use row-level locking and avoid long transactions.

4. Spot Allocation

Future improvements

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

Dynamic Pricing: Adjust rates during peak hours.

Sensors: Use IoT for spot availability tracking.

Mobile App: Pre-book spots or pay online.

EV Charging: Include charging stations.