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.

• Reserve a spot
• Process payment
• Leave a spot
  • Support leaving early
• Gate Check in / check out
• No show handling : Car spot is freed automatically at the end of reservation time

• Out of scope : car overstaying its spot.

Non-Functional Requirements:

• Strong consistency when
  • making reservation : available spots
  • making payments : payment method is correct
  • Check in / out
• High availability. Users can't park/get out is system is down.
• Don't need a lot of data (up to 1000 cars).
• Multiple parking locations. Each location with up to 1000 cars.

# Data model

• Booking (256 bytes)
  • check-in / check-out
• Locations (256 bytes)
  • booked count
  • total spots

# Capacity Estimation

100 Locations, 1000 spots / locations, 5000 bookings / day / location

=> # bookings / day = 100 * 5000 * 256 = 500K * 256 = 128M = 1.28 GB / day

=> 5 year = 1.28 * 360 * 5 = 2.3 TB => 3 TB

# DB design

• Given strong consistency requirements and relatively low data storage, a SQL db like postgres is a ideal choice.

API Design

GET /available_spots (location_id) -> Spot Count

POST /start_booking_spot (location_id) -> payment_url

POST /on_payment_success (payment_id)

POST /enter_spot (booking_id)

POST /leave_spot (booking_id)

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

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.