System requirements

Functional:

List functional requirements for the system (Ask the chat bot for hints if stuck.)...

• Users should be able to check in upon arrival and check out when they leave
• Users should be able to pay for their parking
  • Users should have the ability to extend parking if needed
  • Users should be notified of their parking being expired
• Users should be able to view available parking spots in real time
• Users should be able to reserve a spot ahead of time
  • Users should be able to receive directions to reserved parking spot

Non-Functional:

List non-functional requirements for the system...

• User data and payment information should be encrypted and through secure payment gateways.
• Reservations and check-ins should complete less than 2 seconds
• The system should be highly available, 99.9% of the time
• The system should handle a growing number of users and parking spots

Capacity estimation

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

1000-5000 attendees during an event parking, assuming 2 of them in a car, we could have 2500 DAU for one parking lot.

Let’s assume that there are 10 parking lots in each state, with each lot having 100 spots.

10 lots * 100 spots * 50 states = 50,000 spots nationwide

Let’s say every spot get reserved each day, meaning there are 50,000 reservation requests / day

Each reservation will have - an id (8 bytes), parking lot id (8 bytes), parking spot id (8 bytes), check in time (8 bytes) and check out time (8 bytes). Rounding up, it will have 100 bytes of info

50,000 reservations/day * 100 bytes for a reservation = 500,000 bytes or 0.5MB of data a day

0.5MB/day * 365 days * 2 = 400 MB in 2 years which is reasonable for a SQL database

Since we value consistency, (ie: we don't want to double book our spots), I think we should use a SQL DB since its strong ACID properties.

This seems to be a write heavy system, since most people will be reserving spots. Writes would be check in, check outs to the parking lot and secure payments. Reads would be viewing spots ahead of time.

API design

Define what APIs are expected from the system...

We can use HTTPS since there is no need for WebSockets or GraphQL

Users should be able to view available parking spots for a specific lot in real time

• GET parking/available-spots/parking-lot-id/start-time/end-time
  • returns the available parking spots for a specified parking lot at a certain time in and out

Users should be able to reserve a spot at the lot ahead of time

• POST parking/reserve
  • body {parking-lot-id, parking-spot, start-time, end-time}

Users should be able to pay for their parking

• Continuation of POST parking/reserve
  • after the spot is reserved, the user is redirected to third party payment platform Stripe
  • Returns a payment token
• GET parking/reservation-confirmation
  • returns reservation ID

Users should be able to check in and park in the spot upon arrival

• POST parking/check-in
  • body {reservation-id, parking-lot-id, parking-spot-id, check-in-time}

Users check out when they leave

• POST parking/check-out
  • body {reservation-id, parking-lot-id, parking-spot-id, check-out-time}

Database design

Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...

Since we value consistency, (ie: we don't want to double book our spots), I think we should use a SQL DB since its strong ACID properties. This is feasible as proven above.

User

• name
• User Payment Info

Reservation

• reservation id (primary key)
• parking spot id (foreign key)
• user id (foreign key)
• start time
• end time
• payment status (paid, unpaid, cancelled)
• completion status (completed, inprogress, cancelled)

Parking Spot

• parking spot id (primary key)
• parking lot id (foreign key)
• check in time
• check out time

Parking Lot

• parking lot id (primary key)
• capacity

Transactions (A transaction is car checking in or checking out)

• transaction id (primary key)
• check in time
• check out time
• user id (foreign key)

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...

API Gateway for the user to get redirected to the correct server

Payment Service like Stripe to process our payments and send confirmation to the user

Message Queue to send requests to Reservation Service to ensure that requests are processed one at a time and there are no double bookings.

Transaction Monitor in case someone doesn't check out of their reservation or never checks in, indicating further action needed to be taken by an admin

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...

Based on the above API, we can create the following three services.

1. Users can check the availabilities of spots and then reserve a spot → Reservation Service
2. Users can pay for a spot → Payment Service (external)
3. Users can check in or check out → Transaction Service

The Reservation Service can call on the DB to provide the spot availabilities for a user to reserve if they like. (parking/available-spots/parking-lot-id/start-time/end-time)

The Reservation Service writes to the DB with information when user makes a reservation (POST parking/reserve).

The Reservation Service then creates a request for payment through a redirect URL that returns to the client

The client is now directed to the Payment Service. Once processed, the Payment Service returns the reservation id

Once reserved, let’s say a user arrives and checks in at their spot.

The Transactions Service is called (POST parking/check-in) to store the check in time at the correct reservation and spot.

The same happens for when a user leaves and checks out (POST parking/check-out).

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...

The trade off of using a SQL DB is latency, however here I believe it is necessary for atomicity and consistency in order to only have one reservation per parking spot. This prevents any double booked spots.

Failure scenarios/bottlenecks

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

What happens if a user forgets to check out?

What happens if a user doesn’t check in or doesn’t show up?

• We have a Transaction Monitor that monitors transactions and can send notifications. This can be in the form of a stream, like Kafka.
• Reservations that have no check ins or check outs can notify administrators.

How do we prevent reservations from being double booked?

• We can use a Message Queue system, like Kafka.
• Message Queue Model
  • Pub/Sub
• If the reservation is already taken, then return an error message to the user

Future improvements

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

Future improvements could be to have more features, such as vehicle type and extending parking.