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:

• List the key non-functional requirements (eg low latency, scalability, reliability, etc.)...
• Scalability: We want to add a load balancer between the client and the server to distribute client requests across all the available servers. We can consider using a load balancing algorithm like weighted round robin
• Availability: Have a replica database (or two) to handle the read operations coming from services. The primary database will be used for writes.
• Low Latency: Use caches where it makes sense; add both caches to the backend services and to the frontend services to keep the DB operations to a minimum (which take longer than cache operations)

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

The main functionality of this application:

• Reserve parking spots
• Processing payment
• Check in/check out

These do come with caveats, such as handling situations where a reservation does not show up

Models:

• Parking lot
  • id, related parking spots
• Parking spot
  • id, related parking lot, related user
• User
  • id, payment information
• Reservation
  • id, user id, parking spot id, has paid, check in time, check out time, has_checked in, has_checked_out

To break it down, these are the API endpoints we will need for this:

• POST /parking/reserve
  • Params include user who is reserving the spot and the parking lot id
  • Responsible for reserving a parking spot
• GET /parking_lot/reservation
  • Params include the parking lot id, date
  • Service for checking if the parking lot has any availability
• GET /parking_spot/reservation
  • params include parking spot id, date
  • Service returns if the spot is available at the specific date
• GET /user/reservation
  • Params include user id, date
  • Service returns whether the user has checked in, checked out, or never showed
• POST /parking/payment
  • Params include the spot reserved and the user
  • Service to process user payment

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

Design for payment processing:

• Client sends a request to POST parking/payment, sending the user ID and parking spot
• Load balancer to distribute the request across servers
• Server processes request sends it to the parking payment service.
  • This service takes the user id and the parking spot. The service should check the user cache for user payment details. If the cache misses, we check the user DB. If they have none, then we have to send a response to tell the UI that we need the payment details
• The server checks the reservation cache to see if the user has reserved the parking spot so we don't duplicate
• If the cache misses, we check the reservation DB. If there is no reservation for the user and parking spot, we create one and write to the primary DB. (GET user/reservation)

Design for creating a parking reservation:

• Client to request a reservation at a certain parking lot (POST /parking/reserve)
• Load balancer processes request and distributes to available servers
• The server processes the request and checks the user for auth and rate limiting. If all looks good, we send the request to the reservation service
• The parking reservation service does the following:
  • Checks to see if there are any available spots in the parking lot (GET parking_lot/availability). It first checks the parking lot cache to see if there are any spots available. If the cache misses, check the parking_lot DB.
  • The service should run a query to see if there are any parking spots without reservations for the specific date
  • If there is availability at the lot, we write to the reservation table and mark the row as "unpaid"
  • Update the parking spot row as 'pending' - if the user doesn't reserve in a deadline, run a job to mark as available again
• When the service is complete, we send a response to the client that we the user has a pending reservation and link them to the payment page

Design for check in/checkout:

• Client sends request (GET parking_spot/reservation)
• Server sends the request to the reservation service
• The reservation service checks the reservation cache/DB to see if the check_in/check_out fields have dates.
• Based on the query, we send a response to the UI as either not checked in, checked in, or checked out.
  • Not checked in - no check in date, no check out
  • Checked in - checked in but does not have check out
  • Checked out - has both checked in and checked out

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

The check in/check out service is going to mainly serve to determine if an individual parking spot has been used. It should be straightforward when querying for a single parking lot, but we could improve it if we wanted daily reports for parking lots. We could update the service to run a daily job that would generate a document that describes the status of each parking spot in a parking lot.

The reservation system requires reads and writes to multiple tables. It has to read from multiple tables and also ensure that multiple people aren't reserving the same spot. To make sure that this doesn't happen, we would use a Redis lock on the parking spot, keyed by the spot id, user id, and set a timeout for 10 minutes. This will ensure that if a user doesn't end up reserving the spot, the spot can be reserved by a different user.