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:

• Consistency > Availability
• Low latency read/write calls
• Read ~equal to writes
• Concurrent request and DB consistency handling

DB Design

parking

• parking_id
• status <AVAILABLE, RESERVED, OCCUPIED>
• checkin_timestamp
• checkout _timestamp
• allowed_checkout_timestamp # This can be used to compare and penalise the user
• registration_number
• dimension_size

API Design

GET /parking/?query_param as

[{

parking_spot, status, vehicle_number, parking_allowed_till,

}]

POST /parking/:parking_id/reserve

Rquest payload

{

"registration_number": ,

"mobile_number": <>,

"username": <>

}

POST /parking/:parking_id/pay

Response

{

"msg": SUCESS/FAILED

}

POST /parking/:parking_id/park

Req payload

{

"vehicle_number": <>

}

POST /vehicle//check-in

POST /vehicle//check-out

High-Level Design

Core Constraints

• parking fetch - Any status
• for reserve - status needs to be in AVAILABLE
• checkin/checkout - Any status / independent of status
• park - statys needs to be in RESERVED

GET listing can be directly fetched from DB

parking table can be queried using status = AVAILABLE

POST /reserve

parking spot can be reserved from user

Concurrnecy handling

Its possible that more than 2 users try to reserve a spot, hence we can take a pessimistic locking on DB

This way no 2 users would be able to take action

checkin

checkout

These 2 APIs are straightforward just updating fields in the parking table

Validation can be whether these spots are in RESERVED state or not

Detailed Component Design

1st deep dive-

Flaw with existing reserve

Taking lock on DB level can be cruelsome for DB . we would be blocking the status of the parking spot until payment is done, which can be dependent on Payment GW. Transaction and lock will be blocked till API receives the response

Introduce redis instead.

create a key : {user_id, vehicle_number}.

This way other req will first check if the key exists, and if yes that means parking_spot is already under some operation

2nd DD -

On reservation, 2 cases are possible

• Car never comes
• Car comes and status moves to OCCUPIED
  • Now this depends on business - We can either tow / can start penalising
  • For now, we can penalise
• In both the cases, we can run a CRON to check if status is RESERVED and has exceeded the expected_checkout_timestamp, we can move the spot to AVAILABLE again