System requirements


Functional:

  • vehicle entry
  • exit
  • parking allocation for different vehicle types
  • accept payments on exit



Non-Functional:

  • reliability: the system needs to be highly fault tolerant (we don't want cars staying in the queue on entry and exit)
  • latency: instant payment, minimal wait on entry/exit
  • availability: maintain high uptime 24/7
  • scalability: serve hundreds of cars entry and exit every hour


Capacity estimation

Traffic assumptions:

  • for parking lot for 1000 places
    • 100 entry-exit per hour
    • 100 payments on exit per hour
    • to avoid bottlenecks let's assume 500 entry-exit per hour (peak times)
    • 500 entry/exits * 24 hours * 365 days * 5 years = 21900000 entry/exits for 5 years


Storage assumptions:

  • Assume each parking session have:
    • session id (16 bytes)
    • start datetime (8 bytes)
    • end datetime (8 bytes)
    • car type id (1 byte)


total size: 33 bytes, let's take a bit more, 96 bytes

total size for a month: 21900000 * 96 = ~2,5 GB for 5 years



  • Assume we have a counter of available parking places per type
    • type id (1 byte)
    • type name (20 bytes)
    • place price (8 bytes)
    • total places (4 bytes)
    • current places (4 bytes)


total size: 37 bytes, let's take 96 bytes

total size for a month: 21900000 * 96 = ~2,5 GB for 5 years


  • Assume payment-session mapping table
    • parking session id (16 bytes)
    • payment id (16 bytes)


total size: 32 bytes, lets take 48

total size for a month: 21900000 * 48 = ~1,25 GB for 5 years


  • Assume payments table:
    • payment id (16 bytes)
    • amount (8 bytes)
    • status (32 bytes)
    • payment datetime (8 bytes)


total size: 64 bytes, lets take 128

total size for a month: 21900000 * 48 = ~3 GB for 5 years


Insights:

  • given the low load and need in relations, the system can go well with PostgreSQL, we also need to keep replicas of database to ensure high reliability and availability
  • can improve performance of db by periodical archiving of finished sessions
  • payment gateway should always be up and running, it can be an external component
  • a DB and server needs to be placed close to a parking location to reduce latency




API design

  • entry()
    • inputs: carTypeId, current datetime
    • output: sessionId or None
  • isParkingAvailable()
    • inputs: carTypeId
    • outputs: bool indicating availability of parking place for requested type
  • openEntryBarrier()
  • openExitBarrier()
  • exit()
    • inputs: sessionId
    • output: paymentSessionId
  • parkingPlacesCountNow()
    • outputs: number of parking places currently available per car type



Database design


  • parking_sessions:
    • session_id (16 bytes) - primary, indexed, uuid
    • start_datetime (8 bytes) - utc datetime
    • end_datetime (8 bytes) - utc datetime
    • car_type_id (1 byte) - foreign -> parking_places (type_id)


  • parking_places:
    • type_id (1 byte) - primary, indexed, int from 1 to 9
    • type_name (20 bytes) - text (20 chars)
    • place_price (8 bytes) - double
    • total_places (4 bytes) - int
    • current_places (4 bytes) - int


  • payments2parking
    • parking_session_id (16 bytes) - foreign -> parking_sessions(session_id)
    • payment id (16 bytes) - foreign -> payments(payment_id)


  • payments:
    • payment_id (16 bytes) - uuid
    • amount (8 bytes) - double
    • status (32 bytes) - text (success, error etc.)
    • payment_finish_datetime (8 bytes) - utc datetime


payments2parking allow having



High-level design

You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...








Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...






Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...






Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...






Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.






Future improvements

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