System requirements


Functional:

  1. Reservation:
    • Users can reserve a parking spot through the system.
    • Users can complete the reservation by making a payment.
  2. Parking Management:
    • Allocate parking spots based on user reservations.
    • Handle different vehicle types.
  3. Entry and Exit Management:
    • Track vehicle entry and exit from the parking lot.
  4. Error Handling:
    • Address scenarios where users make reservations but don’t show up, possibly charging a fee for the first 24 hours.


Non-Functional:

  • Performance(low latency , hight throughput) - can be achieved by using CDN, caching available free spots (redis), termination https , etc.
  • Scalability(vertical/horizontal) - k8s and docker can help with horizontal scaling.
  • Availability - can be achieved by using load balancing (nginix, haproxy) , replication, health check, backup server
  • Security - using firewalls, rolebase model, OATH, .
  • Reliability.
  • Consistency - it can be achieved by using sql db, that guarantee ACID.



Capacity estimation

Number of parking lots = 1000

Parking lot capacity = 200

Reservation requests = 200 * 1000 = 200 000






API design

API used by user:

checkCapacity(lot_id, vechile_type, start_time, end_tine) [is_free, price] - checks if parking lot has a free spot and returns price


reserveSpot(user_id, lot_id, vechile_type, start_time, end_time) -

returns reservation_id and price. Also forwarded on 3d party payment system.


completeReservation(reservation_id, payment_token) - after payment we need to complete payment procedure


API used by parking lot:

vechile_arrived(reservation_id, time)

vechile_left(reservation_id, time)






Database design

Reservation table:

  • Reservation_id(key)
  • Spot_id(foreign key)
  • User_id(foreign key)
  • Payment_status
  • Start_time
  • End_time
  • Stuts

User table:

  • User_id(key)
  • Contact_info

Vechile table:

  • vechile_id(key)
  • user_id(foreign key)
  • type

Spot table:

  • Spot_id(key)
  • Lot_id(foreign key)






High-level design

Parking lot - notifies when car arrive or left

Client - user , that wants to get parking spot

Api gateway - mediator fro http requests

Reservation service - checks for empty place and update reservation in database

Payment service - 3d party for payments





Request flows

checkCapacity request handles by reservation service. It checks if we have an empty spot.

reserveSpot request - handles by reservation service. Adds. a new reservation in the system and redirect user for payment service.

completeReservation - after payment, user confirms that spot was paid by token.


vechile_arrived - notifies, when car arrived on parking lot.

vechile_left- notifies, when car left from parking lot.




Detailed component design

For reservation we can use first fit slot allocation or time-slot reservation with time intervals



Trade offs/Tech choices

Nosql db provides good horizontal scaling, but for us most important to have consistency, I mean we should prevent double booking of the same spot. SQL BD it is good choise , for instance PostgresSql





Failure scenarios/bottlenecks

Backend service are stateless. DB will be a bottleneck , it will difficult to scale. We can partitioned DB by parking id. Also we should use some heathcheck system.


In case of db crashes , would be better to use master-slave db approach with replication of db instances.




Future improvements

I believe that we use need to use CDN