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.
• Allow user for a monthly pass
• One slot can not be booked by more than 1 users
• User can cancel the request and then the slot should be available for booking
• Payment should be processed for refund in case of cancellation
• Allow waitlist for the the users and users which are in queue should be notified when the slot is available

Non-Functional Requirements:

• System should be highly available.
• Transactions should be atomic and having strong consistency.
• Design for failure - System should be fault tolerant.
• User should have seamless fast experience to reserve parking slot.
• Handle concurrent transaction gracefully for same parking slot.
• System should be able to handle load at peak time

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

View available slot

GET api/v1/parking/{parking_id}/slots

Response - map of slot view from CDN

Book Slot

POST api/v1/parking/{parking_id}/slots

Param = {slot id : 123}

Response = 200 {booking_id} OR {waitlist_id:123}

View current booking

Get api/v1/reservation/{reservation_id}

Response = {order_id:123, slot_id:123, status:booked}

View past bookings

Get api/v1/booking

Request = {start date:12-12-1999, end_date:12-12-2000, offset=1}

Cancel booking

Put api/v1/reservation/{reservation_id}

View waitlist status

Get api/v1/reservation/{reservation_id}/status

Gate check-in/check-out

Post api/v1/Entry AND api/v1/exit

Param - user token

Park/Unpark Vehicle

Post api/v1/vehicle

param - user token, slot id, reservation id, action: park

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.

Booking flow -

1) User will load the parking map from CDN. CDN would be pull based in case of low load otherwise it would be push based.

2) User will pick the slot from available categories - car, bike, Van/large size vehicle. To handle concurrency, slot would be locked for the given user for next 10 mins to let the user complete the transaction. Meta service would hold the lock and make an entry in DB for same.

3) Booking service will proceed with transaction. Transactions would be serializable and would be completed with the help of 3rd party PSP.

4) Upon successful completion, user would be notified via email or SMS.

5) if waitlisted, user would be provided with waitlisted id. Waitlist id would be created in redis sorted set.

Waitlist flow-

1) if any user cancels the reservation, redis sorted set would be updated.

2) first eligible user would be notified in case of availability. if user does not book in next 1 hour then 2nd user would be notified to proceed with booking.

Failover -

Redis would maintain session id, if any instance of booking service goes down then the request would be picked by another instance from existing session id.

DB will have 2 more replicas. and entire transaction would be in sync to maintain strong consistency.

Rate Limiting -

API gateway will have rate limiting to prevent DOS attacks.

Concurreny Issue -

Slot would be locked for 10 mins for the given user. if 2 lock request comes at same time then based on time order protocol, preference would be given.

Notification -

Async kafka is used for non critical notifications. Waitlist will have separate topic and will be having more priority.

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.

Booking Service - It is cluster of multiple instances with automated failover. The cluster can scale out during high load. Session id would be maintain in redis so that any instance can pick ongoing transactions.

For waitlist - Sorted set of Redis would be used to maintain transaparency.

Fast experience - CDN would hold the current map. The map would be loaded to CDN based on push method so that user is always getting the latest status.

Transaction integrity - All transactions would be serializable isolation level in db that would avoid phantom reads too.

Design for failure -

1) In case of failed redis, the session id would be switched back to be maintained in JWT token within client browser.

2) Circuit breaker would be in place with exponential backoff if any of the service gets hanged.

3) Kafka failure - Topics would be replicated. In case of complete failure. Notification would be lost. To maintain critical notifications such waitlist, Write ahead log can be used to replay events.

Retry Idempotency - If user tries to book same slot again, the same idempotency key would be used for the second try as well.