System requirements


Functional:

  • Ability to find an empty parking slot
  • Ability to find the most efficient slot based on user car specificities



Non-Functional:

  • Consistent: One slot can't be shared by two vehicles
  • Performant: Booking a slot should be quick and user-friendly
  • Available: System should seamlessly handle peak of traffic (peak hours) as well as managing high volume of data (who is parked where, but also additional data like overall occupancy)




Capacity estimation

Estimate the scale of the system you are going to design...






API design

Define what APIs are expected from the system...






Database design

Search service:

Only available slots will be stored there

  • Available slots
    • Identifier
    • Parking identifier (where). Can be used for sharding in order to speed up search lookup
    • Availability timeframe
    • Size compatibility
    • Features (like electric charger)
    • +Additional info based on requirements, like distance to the exit for instance




High-level design

  • Availability service: System ables to determine which slots are available and if there is one among them fitting requirements (car specificities mostly). It will also be in charge of ordering available slots in order to find the most efficient one (based on car specificities and available slot specificities)
  • Booking service: System responsible for persisting the booking, as well as somehow update the slot availability.
  • Payment service: System in charge of processing the payment linked to a booking.
  • Front-end: User interface in charge of translating user interaction into requests for the system, as well as to ease as most as possible user experience
  • Load balancer: Sit in front of the API gateways in order to balance traffic and avoid bottlenecks
  • API Gateway: responsible for request routing, rate limiting, authentication & authorization and emetting metrics




Request flows

See sequence diagram







Detailed component design

Search service: Find the best slot

  • Take into account vehicle specificities: size/type as well as requirements like electric charger
  • Find available slot matching requirements. Slot for large vehicles will be taken into account but exact match should be taken into account first!
  • Algorithm:
    • Greedy: take the closest to the exit for instance
    • Weighted score: Assign score to slots based on different factors (distance, size compatibility, features, etc) and pick the best one
    • Multi criteria decision analysis (MCDA): To be considered especially If factors list is too wide (many user preferences to take into account for instance)
    • => I would go for greedy algorithm at first, which is simple and faster to implement and refine it based on usage metrics
  • Return the answer to the user in order to display a message





Trade offs/Tech choices

The whole system requires consistency to avoid double booking. Therefore a Mysql database (ACID) would be a good choice here. However it may not scale properly in case of high traffic. If leveraging sharding and replication (read-only replicas) is not enough, switching to a NoSQL DB may be a good choice. CassandraDB for instance has a tunable consitency option which would meet the requirements while keeping the whole system available.






Failure scenarios/bottlenecks

  • Double booking: even with a Mysql DB, double booking has to be taken into account as two user may accurately see a slot as available for them but only one should succeed to book it (on booking service). Kind of lock mechanism is most likely required to avoid a slot to be book by two users
  • Unavailable slot: In case of error during a booking, pro-actively providing alternative to the user would provide a better user experience
  • Scaling issue: See above. Several ways available, first fine-tuning existant and consider alternative if it doesn't suffice





Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?