System requirements

Functional:

• Book a parking spot
  • Allocate free parking spot
  • Payment processing at reservation
  • Refund if booking is canceled
• Find disabled friendly spot
• Users can review their payment history

Non-Functional:

• Response time < 200ms for booking
• Payment done under 2s
• Scability to handle peak of traffic during events and or holidays
• Payment transactions have to be secure
• Users must be strongly authenticated
• All activity must be logged

Capacity estimation

• About 1000 parkings lots
• Reservations requests:
  • 10-hours window of activity
  • About 200K reservations a day (~6 requests/s)
  • 2x-3x increase during events or holidays so 500K (~14 requests/s)

API design

list GetParkingLots()

string GetParkingLotDetails(int parkingLotId)

int FindFreeParkingSpace(int parkingLotId, bool disabledFriendly)

int BookParkingLot(int parkingSpaceId, datetime start, datetime end)

string GetReservationDetails(int reservationId)

bool CancelBooking(int reservationId)

Database design

• ParkingLots
  • [PK] int id
  • string address
• ParkingSpaces
  • [PK] int id
  • [FK] int parkingLotId
  • [FK] int reservationId
  • bool isDisabledFriendly
• Reservations
  • [PK] int id
  • [FK] int parkingSpaceId
  • [FK] int paymentId
  • [FK] int userId
  • datetime reservationDate
  • int durationInHours
• Users
  • [PK] int id
  • string email
  • string password
  • datetime registrationDate
  • datetime lastlogindate
• Payments
  • [PK] int Id
  • int amount
  • string paymentsDetails

High-level design

• Load-balancer to distribute evenly the requests among the application servers
• Database with strong consistency (RDBMS)
  • Usage of transactions for reservations to handle concurrency scenarios
  • Active-active topology to handle failures
  • A relationnal database should be able to handle the planned 6-14 requests/s
• Parking lot details can be cached as they don't change often
• Logging database use a append-only model

Request flows

• User login to the reservation platform
• User list different parking spaces
• Reservations:
  • Ask for a free parking space
  • Try to book the free parking space
  • Pay for the reservation
• Cancellation:
  • Delete the reservation
  • Refund the user

Detailed component design

The platform can authenticate by a third-party provider using the OAuth protocol

We need a distributed lock mechanism to handle possible concurrent reservation of the same parking space

Possible solutions:

• Having a flag in the database
• Use datastore like Redis that serialize requests (possibilty to have a TTL so we can have a maximum duration for reservation session)

Trade offs/Tech choices

A RDBMS is used to handle well the transactions but it won't scale very well if we need to support much more requests

Failure scenarios/bottlenecks

The active-active topology can handle the failure of one of the database node

Future improvements

Possibility to handle different vehicules types (motorbike, SUV, camping car etc.)