Requirements

Functional Requirements:

• Allow reservation of a parking spot. Handle up to 30 days in advance.
• Venue owner will have to enter details of tiers and pricing.
• 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:

• Strong consistency for handling booking. Make sure no double booking. Handle up to 50K users trying to book at once.
• Low latency in terms of searching and viewing parking spots.
• High availability - avoid downtime.
• Should scale for multiple users trying to book multiple parking spots across parking spaces in case of a major event.

API Design

Here are the core entitites:

1. Venue

• name
• address
• number_of_standard_spots
• cost_of_standard_spots
• number_of_premium_spots
• cost_of_premium_spots
• ownerId

1. Owner

• Name
• email
• phone

1. User

• Name
• Email
• Phone

1. Booking

• VenueId
• UserId
• StartTime
• EndTime
• Status - Available, Reserved, TemporarilyReserved, InProgress

A. POST /venue/create

Headers - JWT/session token - validate user and get user ID

Body - {

Venue details

}

B. GET /venue/details - To view the available options and pricing

Headers - JWT/session token - validate user

C. POST /booking/create

Headers - JWT/session token - validate user and get user ID

Body - {

VenueId

Standard/Premium

StartTime

EndTime

}

D. PATCH /booking/update

Headers - JWT/session token - validate user and get user ID

Body - {

VenueId

Status - InProgress for check-in and Available for check-out or no show

}

High-Level Design

The user and the venue owner will be hitting the same API Gateway and the API Gateway will handle load balance in authentication rooting to the right API end point rate limit and so on. From here we will be able to access all for API that I designed so for when you creation. The when you on a will be able to give details about the specific when you and we will be storing it in our when you database and for this when you date I going to be far more than the rights because the number of venues that get added everyday or every month is going to be relatively less but the amount of people who want to view the venue and other details I going to be more. We will have another and getting the venue details when the user wants to access what when you surprised how many open spots I want to use this we will maintain database for this is well which is the same one where the venue? At the same time the user can also check for a specific date and time how many open spots available. We will then have another API full creating bookings so once this API is hit we will temporary whatever the use I wanted to book and we will read them to a third party payment which is going to be increase so we going to wait for the response from this third party payment service? Once the payment is done we will move it from temporary reserve to reserve.

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.