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:


  • High availability system, expecting high traffic (millions of concurrent users)


API Design

GET /parkings

It gets a list of parkings, with locations and availability, SSE for spot availability. Potentially could be shown in a map display (returns lat, long)


GET /parking

Includes real time subscription SSE for spots available when accessing the parking detail page


POST /reserve

Triggers a transaction to:

  • Put a hold on the payment method
  • Reduce availability on parking
  • Trigger a notification email (in a queue)



High-Level Design

SQL Database (Postgres)

  • Users
  • Parkings
  • Reservations (userId, parkingId). Includes price and, if relevant, spot type.


Replica for read operations


Queue

Simple queue to send email notifications async (without blocking the main reserve workflow).


Notification service

Send emails and SMS with reservation info and updates.


Cron updates service

We may also check for reservations getting to the end, and send a notification. It could be a cron job, checking every minute a reservation is about to end, marks the notification sent in the reservation record.


Listing service

Returns the parking or parkings endpoints, querying the database for relevant spots. It sends updates to the client via SSE.


Reservation service

Writes to the main database and manages payment transaction.


End user client

  • Mobile app (app stores)
  • Web portal (hosted in CDN)
  • Machine app (e.g. android app for the specific machine, in addition to the other clients it may handle cash)


Parking owner client

Dashboard with parking metrics. It may include some configuration (spot availability, schedule, etc.). It changes the `parkings` record.


Load balancer

Routes requests to available server




Detailed Component Design

Reservation service it the key component here, since it needs to complete the payment transaction and block the spot on the database, using an optimistic concurrency control to avoid racing issues and secure payment.


Also the SSE, the client subscribes to the payment. A LISTEN/NOTIFY process in postgres makes the listing service return real time availability on spots.