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

• Consistency (the same spot should not appear empty when it is being used and vice-versa)
• Atomic writes
• High Availability
• Scalability for usage increase

Capacity Estimation

Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...

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

CreateReservationCart(startTime, durationInHours) ReservationCart // contains info about reservation, price and userID

CreateCheckoutCart(userId) -> CheckoutCart // contains info about stay, startTime and hours spent, price and userID

MakeOrder(cartId)

GetAvailablePaymentMethods() -> PaymentMethods[]

SelectPaymentMethod(method) -> PaymentInstructions

High-Level Design

The server will have basically 3 components:

• Cart: It will be responsible for Creating/Storing the ReservationCart and CheckoutCart.
• Payments: Will be responsible for communicating with external PSP and signalizing to Cart component whether payment was successful or not
• Reservation will receive a makeReservation from Cart and will try to reserve the spot. If the spot is already reserved, it will return an error: spot already reserved, which will cause Cart to cancel the current cart object and store it in the DB and send a message to Payments to revert the payment.

The availability could be achieved with redundancy, every write will be replicated to another server that will be consistent with the main DB. This will ensure that if the first one goes down, the second one could assume its position. And given that the parking slot only contains up to 500 spots, that dual write shouldn't add significant latency as the number of write should be low.

Scalability issue will be divided in 2 sections:

• Increasing demand but keeping the 500 spots:
  • leveraging queues to avoid overloading both the payments and the cart components.
  • The number of spots is too small to consider scaling out the database, so no need for that
  • use user-level rate limiter and service-level, so that if the service is under a huge demand, then the user will be put in a queue to be able to make reservation requests
• Increasing significantly the number of spots:
  • If the system increases the number of spots, then we could handle it by increasing the number of servers on demand, and scaling out the DB by partitioning the slots on each partition, EX: the first 10k slots would be in 1 partition, the next 10k in the other, and so on. This would allow servers to scale out independently would solve the scalability issue while maintaining consistency as one DB partition only needs to take care of their own spots.

Database Design

Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...

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 server will have basically 3 components:

• Cart: It will be responsible for Creating/Storing the ReservationCart and CheckoutCart.
  • CreateReservationCart: When the user selects a reservation in the frontend, the FE will make a request for Cart to create a cart for that reservation, it will contain the reservation period, the userId linked to the reservation and the cost.
  • CreateCheckoutCart: The same thing is for this endpoint. The user will have 5 minutes to finish the payments for each cart.
  • MakeOrder will get the cart, validate whether the cart still applies to the current time and check with reservation component if the spot hasn't been filled yet. If the validations pass, it will go ahead to processing the payment.
• Payments will communicate with the external PSP
  • it will send a request to either process a new payment or refund an existing one.
  • It will have a webhook to listen to the PSP responses (payment succeeded or not), it will signalize to Cart that the payment succeeded and that it can move forward to the reservation
• Reservation: will receive the calls from Cart to verify whether spots are available, fill/empty a given spot when the cart payment succeeds
  • Dealing with dual reservation: The design will not lock the spot when the user moves to payment, instead, it will keep it available and if 2 payments are processed for the same spot, whichever gets to the reservation component first is reserved. This is guaranteed to work due to levering ACID properties of the local DB.
  • So, when the second payment arrives and the reservation sees that the spot is already filled, then it will return an error: `Error: spot already filled`, this will get back to cart that will trigger a refund for the payments component that will request the external PSP to refund it.