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:

  • Reliability
  • High Availability (System should always respond, if request if failed becaurse of overload it should be automatically retried by Front End)
  • Secure
  • Strong Consistency
  • Scalability


API Design

RESERVE PLACE

POST /reserve { "car_plate": "str", "lot_id": "str", "check_in_time": "timestamp", "check_out_time": "timestamp" } RESPONSE { "reserve_id": "str", "price": "str" }


CheckIn

REQUEST

POST /lot/check-in { "car_plate": "str }

RESPONSE

SUCCESS

or

NO ACTUAL RESERVATION FOR THIS VEHICLE FOUND


CheckOut

POST /lot/check-out { "cat_plate": "str }


RESPONSE

SUCCESS

or

THERE IS A PARKING DEBT FOR A VEHICLE


List of parking lots

GET /parking { lot_ids: ["str", "str", ...] }



GET /parking?free=ture&size=medium?check_in_time&check_out_time { lot_ids: ["str", "str", ...] }



GET /parking/{id} { lot_id: "str" }


POST /parking/debt { "car_plate": int }



POST /parking/pay

REQUEST

{ "car_data": "str" "car_plate": "str" }



High-Level Design

  • There should be 3 types of business entities: parking lots, reservations and actions.
  • Data should be consistent, everything can be stored in simple RDBMS.
  • User visits FrontEnd, FrontEnd asks car size and car plate, after user typed it in, FrontEnd makes request for available parking lot of requested size. User click on lot which is good for him, that sends reservation request to BackEnd. After that user have link to payment processing. If payment is processed everything is ok. Camera makes a photo of every plate and autmatically tries check-in/check-out request
  • LoadBalancer is used in case of traffic burst
  • Ingress limits amount of RPS for IP, so users won't overload system by f5 on available place.



Detailed Component Design

  • RDBMS structure:
    • parking_lot: ID, Size (Small, Medium, Big), Price
    • reservation: ID, car_plate, TSTZRANGE, payed, create_time, expired
    • action: datetime, action [check_in, check_out]
  • RESERVATION CREATION:
    • When user create reservation it considers as non free for specified time period for 15 minutes.
    • 15 minutes after create_time it becomes free if payed flag is still false. Free/Non Free logic is Bussiness logic, it is not saved in DB.
    • GiST extension of postgres will provide strong consistency, for TSTZRANGE not overapping reservations. Error will be send to Backend and from backend to FronEnd if trying to send request with overlapping time.
    • If someone created reservation it is not considered "Free", so it is not seen as free for this time period.
  • PAYMENT:
    • If payment is successfull then reservation payment is set to true, otherwise set to false, BackEnd send Client message so client should retry payment.
    • All payments are handled as synchronized requests, so answer will be immediate
  • CHECK/CHECKOUT:
    • check-in works only if there is payed reservation found in correct timescope for the car_plate
    • Parking debt exist in case if there is created parking which is not payed or in case checkout hasn't happened and there is 5 minute after checkout time
    • If parking debt > 0 checkout won't happen