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:

• Prevent over-booking and double payment.
• Strong consistency is required.
• Scalability is not required, the maximum number of user is capped by the parking lot capacity (100-500 vehicles).
• Handle crowded periods e.g. weekend mornings
• Fault tolerant

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

POST api/parking_lot/reservation

{

vehicle_number: str

vehicle_type: str (e.g. SUV, Sedan, truck, bike)

full_name: str

personal_id: str

time: int (minutes)

} -> Reservation {

spot: int

client_id: str

remaining_time: int

}

GET api/parking_lot/reservation?client_id=...

->Reservation

POST api/parking_lot/checkout

{

vehicle_number: str

client_id: str

}

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.

Load Balancer is used for failover, if one server fails, requests are router to another to ensure fault tolerance.

Reservation Service receives the reservation request from the client then sends a request to an external payment service e.g. Stripe. Stripe also handles idempotency and prevents the possibility of double payment.

We create a webhook so that when payment is done, Stripe sends a response back to the server. once this response is received, the MySQL DB is updated

MySQL DB

• we use MySql due to the ACID properties that it has which ensure strong consistency.

Checkout Service is responsible for deleting the row of that specific client.

We use the parking spot id as an idempotency key with TTL equal to the duration of the reservation. We add this key to Redis cache with a status PROCESSING. Once the data is written to mySQL DB we update the status to processed.

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.

MySQL DB

• we use MySql due to the ACID properties that it has which ensure strong consistency.
• client_id is primary key
• The schema of the table matches the body of the request e.g. client_id, personal_id, vehicle_number
• We enable encryption because we hold PII data like the personal_id.
• Since there are at most 500 rows in the database, it can easily fit into one server, no sharding required
• Even if the scale is low, we will have one passive replica. After each write to the main DB, the data is also written asynchronously to the replica.
• We don't expect the database to fail often, so we can schedule alerts to a human oncaller that performs the failover.
• We add a database constraint on the parking spot (UNIQUE) to prevent overbooking. even if the cache is stale, the mysql write will fail and we return an error to the client.

Reservation Service:

• Handles payments via Stripe using a webhook.
• Responsible for creating row in MySql for the clients
• It does polling every one minute to the MySQL database to see the expiration time of a reservation. When reservation expires, it deletes it from the DB and cache and optionally send a notification to the user via an External Service.
• Since we have Redis cache with the idempotency key, if two clients want to book the same spot, this service checks redis, then returns an error