System requirements

Functional:

• Manages vehicle entry, exit, and parking allocation
• Accommodate different type of vehicles
• keep track of available spaces in real-time
• accessibility
  • display available spaces
  • allows users to reserve spots
• security
  • access control
  • surveillance
• user experience
  • mobile push notification
  • payment

Non-Functional:

• Scalability
  • the system can expand to add more parking spots
• Performance
  • allows a growing number of users and vehicles without degrading performance
• Reliability
  • should be operational most of the time (e.g., at least 99.9% uptime) to ensure users can access parking when needed
• Consistency
  • one parking spot can be used by only one vehicle

Capacity estimation

1000+ users/day

• QPS=10^3/10^5=0.1

Tickets are retained for 5 years. Assume each tickets is 1KB

• storage = 10^3*10^3 = 1GB / day
• 365*5=2TB for 5 years

API design

• for users
  • check available spots
    • GET /api/availableSpots
  • reverse a spot
    • POST /api/reserve/spotId
  • pay for a ticket
    • POST /api/payement/ticketId
• for parking log
  • check available spots
    • GET /api/availableSpots
  • vehicle arrive
    • POST /api/arrive
      • reservation or not
      • returns ticket information
  • vehicle leaves
    • POST /api/leave
      • return ticket paid or not

Database design

• user
  • userId
  • email
  • name
• vehicleType
  • motorcycle
  • car
  • van
  • Electric
• parkingSpotType
  • motorcycle
  • large
  • compact
  • electric
• parkingLot
  • lotId
  • floorNums
  • location
• parkingLotFloor
  • floorId
  • motorcycleSpots
  • largeSpots
  • compactSpots
  • electricSpots
• parkingSpot
  • spotId
  • type
  • status
• ticket
  • ticketId
  • entryTime
  • exitTime
  • vehicleType
  • status
• transaction
  • txId
  • userId
  • ticketId
• reservation
  • revId
  • spotId
  • userId
  • startTime
  • endTime

High-level design

Request flows

Detailed component design

• redis as in memory cache
  • keep tracking of expiration time. If expired, trigger a push notification to users.
• message queues are used to decouple services
• in API server, add locking mechanism to ensure that one spot can only be reserved by one customer.
  1. Check Slot Availability in Database: When a booking request is received, the API server first checks the database to retrieve the slot information and determine if it is available.
  2. Acquire Lock in Redis: Before proceeding with the booking, the server attempts to acquire a lock for the slot using Redis. This ensures that no other server can book the same slot simultaneously.
  3. Check Redis for Booked Slots: Once the lock is acquired, the server checks Redis to see if the slot is already booked. If it's not booked, the server proceeds to book the slot.
     1. Book the Slot in Redis:If the slot is not already booked in Redis, the server marks the slot as booked by setting a key in Redis.
     2. Optionally, update the database to reflect the booking status for persistence.
  4. Release Lock: After the booking is confirmed, the server releases the lock.
  5. Handle Conflicts: If the slot is already booked in Redis or if the lock cannot be acquired, the server returns an appropriate response to the client, indicating that the slot is unavailable.

1. payment try queue and deadletter queue to handle failed payments and expired payments.

Trade offs/Tech choices

• Relational database is used to store data because storage requirement is relatively low, and strong consistency is preferred.
• Users can only specify a particular spot through reservation. If a user does not make a reservation, the system reduce a spot based on the vehicle type. This reduce time complexity in tracking all spots

Failure scenarios/bottlenecks

• Single database poses SPOF.
• Single redis server poses SPOF

Future improvements

• add database read replicas, and make sure they sync with write database in real time
• add redis cluster