Requirements

Functional Requirements:

• Allow reservation of a parking spot.
• Process payment for the reservation.
• Enable parking of a car in the reserved spot.
• Support early departure before reservation time expires.
• Gate check-in/out.
• Handle no show.

Non-Functional Requirements:

• Scalability
  • Horizontal: Adding new parking lots or servers
  • Vertical: Enhancing existing parking lots or servers
• Performance
  • Speed of reservation, payment process, gate check-in/out
  • Space optimization
  • Throughput of transactions (reservations, check-ins/outs)
  • Latency during reservation process
• Usability
  • Accessibility
  • Convenience
• Reliability
  • Security
  • High reservation system availability
    • Server redundancy
  • Entrance/exit availability
  • Failure tolerance
    • Fallback mechanisms
    • Server redundancy
    • Monitoring and alerts
    • Reserve spots for over time vehicles
    • Patrols
  • Parking lot/spot allocation (Load balancing)
• Maintainability
  • Cleanness
  • Monitoring/Auditing system
• Consistency
  • Strong consistency on reservation data to prevent double-booking

API Design

Reservation System

1. POST /getRecommendations
   1. Description: Recommend parking lot based on filters like location, time, availability, price, vehicle size, etc.
   2. Input: zipCode, timeRange, priceRange, vehicleSize
   3. Output: A list of recommended parking lots close to the location with price that meet the filters
      1. parkingLotId, price, timeRange, availableSpots
2. POST /listParkingLots
   1. Description: List all parking lots
   2. Input: zipCode (optional)
   3. Output: A list of parking lots close to the location
      1. parkingLotId
3. GET /getParkingLotDetails/{parkingLotId}
   1. Description: Get details of a parking lot
   2. Input: parkingLotId
   3. Output: parkingLotId, priceRate, operatingHours, location, etc.
4. POST /makeReservation
   1. Description: Reserve a parking spot of a given parking lot. The parking spot will be reserved for 10 minutes to process the payment.
   2. Input: userId, parkingLotId, timeRange, vehicleSize, plateNumber, needAccessibility, etc.
   3. Output: paymentId
5. POST /makePayment
   1. Description: make payment for a specific reservation and confirm it
   2. Input: paymentId, amount
   3. Output: status
6. GET /getReservation
   1. Description: Get details of a reservation
   2. Input: reservationId, confirmationId
   3. Output: parkingLotId, timeRange, vehicleSize, needAccessibility, etc.
7. POST /cancelReservation
   1. Description: Cancel a reservation
   2. Input: reservationId, confirmationId
   3. Output: status (success or failure)

Parking Lot

1. POST /checkIn
   1. Description: check in to the parking lot
   2. Input: reservationId, plateNumber, currentTime, parkingLotId
   3. Output: allowPass, leaveTime
2. POST /checkOut
   1. Description: check out of the parking lot, should support early departure and late departure with extra fee
   2. Input: reservationId, plateNumber, currentTime, parkingLotId, lateFeeId (if applicable)
   3. Output: allowPass, lateFeeId, amount
3. POST /payFee
   1. Description: pay late fee (late departure)
   2. Input: lateFeeId, amount
   3. Output: status

High-Level Design

Architectures

1. Reservation System
   1. User interface: can be web or app
   2. API Layer
      1. API Gateway: Handles incoming requests and routes them to service layer
      2. Caching Service: Temporarily stores frequently accessed data, such as parking lot list in a city or parking lot details. By doing so, it reduces the need to repeatedly query the underlying database, which can be a bottleneck, especially during high traffic periods.
   3. Service Layer
      1. Load Balancer: Routes requests to different instances of Reservation Service to prevent overload
      2. Reservation Service: Handles reservation creation/lookup/cancel. Talks to Payment Service to get payment/refund information and to Data System to update reservation data.
      3. Payment Service: Handles payments and refunds. Send back to Reservation Service payment/refund status.
      4. Parking Lot Lookup Service: Handles parking lot search/lookup/recommendations.
2. Data System
   1. Database
      1. Reservation table: stores reservation information
         1. Columns: reservationId, confirmationId, userId, parkingLotId, timeRange, plateNumber, vehicleSize, paymentId, paymentStatus, lateFeeId, lateFeeStatus, needAccessibility
         2. Indexing: reservationId
      2. Parking Lot Table: stores parking lot information
         1. Columns: parkingLotId, priceRate, operatingHours, location, number of spots of different kinds, etc
         2. Indexing: parkingLotId
3. Parking Lot System
   1. User Interface: Gate
   2. API Layer
      1. API Gateway
   3. Service Layer
      1. Gate Service: Handles check-ins/outs. Talks to Payment Service to get late fee information and to Data System to update reservation data for late fee.
      2. Late Fee Service: Handles late fee payment. Send back late fee payment status to Gate Service.

User Flows

1. Make reservations: list parking lots or get recommendations on Parking Lot Service -> get parking lot details on Parking Lot Service -> make reservations on Reservation Service -> make payment on Payment Service -> get confirmation
2. Make payment: There are two payment verification approaches
   1. synchronous: makeReservation API calls Reservation Service to store reservations to Reservation Table with 10 minutes TTL. If user initiates payment within 10 minutes, Reservation Service will delegate the request to Payment Service and waits for a response. If payment is successful, the data entry will be flipped to a longer TTL (can be longer than reservation end time for history lookup), and Reservation Service will send back reservationId nad confirmationId to user.
   2. asynchronous: To handle traffic burst, we can implement a non-blocking system to make reservations. When user initiates the reservation and gives payment details, we can send the request to a queue. Requests in the queue will be processed by Reservation Service, which talks to Payment Service for payment, one by one. If successful, we can utilize webhook mechanism to notify users on web or app, or send out an email notification.
3. Check reservations: getReservation API (requires both reservationId and confirmationId present) -> Reservation Service -> Reservation Table
4. Cancel reservations: cancelReservation API -> Reservation Service -> Reservation Table
5. Gate check-ins: checkIn API -> Gate Service -> Reservation Table
6. Gate check-outs: checkout API -> Gate Service -> Reservation Table
   1. Early departure: pass
   2. Late departure: gives paymentId and the remaining fee -> pay fee on Late Fee Service -> check out with the paymentId again -> pass

Non-Functional Requirements

1. Scalability
   1. To add a new parking lot or expand an existing parking lot, we can simply update data in the parking lot table. If it's a frequent request, we can create a management system to handle that.
2. Performance
   1. To enhance database performance, we can implement database sharding by parkingLotId and read replicas to isolate write and read operations
3. Reliability
   1. Security: Need both reservationId and confirmationId to look up a reservation, need reservationId and plate number to check-in
   2. Reservation service availability: Add server instances to achieve redundancy and use load balancer to assign traffic to different instances
   3. Rate limiting for API calls
   4. Queuing reservation requests using the aforementioned asynchronous payment approach
   5. Failure tolerance
      1. Fallback mechanisms: If a service fails, reroute the request to another instance without user intervention
      2. For vehicles that stay over time, we need to reserve spots for them, and contact customers or call towing companies if staying for too long.
4. Maintainability
   1. Monitoring and alerts: Set up monitoring tools to track system health and performance, allowing for proactive responses to potential issues before they lead to downtime.
5. Consistency
   1. We need to ensure strong consistency on reservation data. When user checks the availability for a parking lot, the system can quickly check the cache for availability, but the final reservation must be committed to the data to ensure that no two users can reserve the same spot simultaneously.

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

API Gateway

1. Description: Handles incoming requests, and retrieves data from caching service for popular queries, or routes to Service Layer

Caching Service

1. Description: Responsible for storing popular queries
2. Caching maintenance mechanisms
   1. The underlying storing system should utilize Time-To-Live expiration strategy and cache purging to remove stale data
   2. Eviction policy: Can be Least Recently used or Least Frequently used
3. We need to ensure strong consistency on reservation data. When user checks the availability for a parking lot, the system can quickly check the cache for availability, but the final reservation must be committed to the data to ensure that no two users can reserve the same spot simultaneously.

Load Balancer

1. Description: Route requests to different instances of services based on different conditions like geographical nearest, numbers of instances spawned, etc.

Parking Lot Lookup Service

1. Description: Handles parking lot search/lookup/recommendations.
2. Consistency vs. Availability
   1. When calculating available spots for a parking lot, the service needs to check both reservation table and parking lot table. This query might take a long time, so in order to enhance user experience when looking up a spot, we could utilize the caching service to handle popular queries. When making the final reservation, we need to ensure consistency to prevent double-booking, which means the request needs to go through reservation service and retrieve data from the database.

Reservation Service

1. Description: Handles reservation creation/lookup/cancel. Talks to Payment Service to get payment/refund information and to Data System to update reservation data.
2. Non-Functional Requirements
   1. Scalability: Can scale horizontally by adding more instances, or vertically by upgrading existing instances
   2. Performance: during traffic burst, There are two payment verification approaches
      1. synchronous: makeReservation API calls Reservation Service to store reservations to Reservation Table with 10 minutes TTL. If user initiates payment within 10 minutes, Reservation Service will delegate the request to Payment Service and waits for a response. If payment is successful, the data entry will be flipped to a longer TTL (can be longer than reservation end time for history lookup), and Reservation Service will send back reservationId and confirmationId to user.
      2. asynchronous: To handle traffic burst, we can implement a non-blocking system to make reservations. When user initiates the reservation and gives payment details, we can send the request to a queue. Requests in the queue will be processed by Reservation Service one by on. Reservation Service needs to first check if the spot is still available from the Database. Reservation Service then talks to Payment Service for payment, one by one. If successful, we can utilize webhook mechanism to notify users on web or app, or send out an email notification. If two users try to reserve the same spot, we will abort the second request, and notify the user of the failure.
      3. Here I recommend asynchronous to avoid conflicting transactions to be processed at the same time
   3. Reliability: Redundant instances behind a load balancer
   4. Consistency: Read operations are consistent. If there is a double-booking during write operation, where Data System returns a collision error, we need to notify users of the reservation failure.

Payment Service

1. Description: Handles payments and refunds. Send back to Reservation Service payment/refund status.

Gate Service

1. Description: Handles check-ins/outs. Talks to Payment Service to get late fee information and to Data System to update reservation data for late fee.

Late Fee Service

1. Description: Handles late fee payment. Send back late fee payment status to Gate Service.

Database

1. Description: Stores Reservation data, parking lot data, and analytics data
2. Data modeling
   1. Reservation table: stores reservation information
      1. Columns: reservationId, confirmationId, userId, parkingLotId, timeRange, plateNumber, vehicleSize, paymentId, paymentStatus, lateFeeId, lateFeeStatus, needAccessibility
      2. Indexing: reservationId
      3. Sharding: parkingLotId, startTime
   2. Parking Lot Table: stores parking lot information
      1. Columns: parkingLotId, priceRate, operatingHours, location, number of spots of different kinds, etc
      2. Indexing: parkingLotId
   3. Analytic data
      1. User metrics
         1. Popular parking lots
         2. User actions (make/cancel reservations, early/late check-outs)
      2. Performance metrics
         1. Response time
         2. Error rates
      3. A/B testing data
3. Non-functional requirements
   1. Scalability: Implement database sharding to distribute data across different instances
   2. Performance: Recommend using relational database to store data, since queries are complicated
   3. Reliability: Database replicas can help recover when one instance is down
   4. Consistency: Read operations can be concurrent. Write operations can be concurrent among different database shards.