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:
- System has to be reliable and strongly consistent.
- Payment has to be deducted correctly.
- DAU 10000
- A spot can not booked twice at a time
API Design
[post] /api/v1/spot/reserve
body: {
row: int
col: int
vehicle_number: str,
vehice_type: enum
reservation_time: datetime
start_time: datetime
end_time: datetime,
idempotent_key: str
}
response: {
reservation_id: str
status: success | failed | No place
}
[put] /api/v1/spot/reserve/{id}
body: {
status: checkin
vehicle_number: str
}
response: {
status: success | failed
}
[put] /api/v1/spot/reserve/{id}
body: {
status: checkout,
vehicle_number: str
}
response: {
status: success | failed
}
[post] /api/v1/payment/reservation/{reservation_id}
body: {
amount: 350,
}
response: {
status: success | failed
}
High-Level Design
- User will put a reservation to the system using client like Mobile or UI.
- The reservation service will check if reservation is possible in the given time frame and for that specific slot.
- Reserve endpoint will use Idempotent key, so that users dont double book.
- If possible user will be handed over a reservation id, by saving the reservation time in database.
- Then user will proceed to pay using convenient payment gateway service like Stripe.
- When user will come at the gate, by providing the reservation id we can determine if we should allow the vehicle to park or not.
- When the user checks out, either at the right time or early.
- We will use idempotent endpoint here so that user don't pay twice.
- For burst request we will be using rate limiter using ip address and Token Bucket algorithm. May be 10 calls in a minute.
- Load balancer will handle the spike of traffic evenly.
- We can also use database sharding to increase the write speed.
- If any user tries to park outside the reservation time, he will not be allowed.
- We can split the spot for a given time like 30 minutes. User can be able to park for 30 minutes, 1 hour, 1.30 minutes etc. To increase read speed, we can use cache service like Redis. We will be saving the available slots in the redis. Which will be updated as soon as there are any changes in reservation time
Out of Scope:
- What happens if vehicle is parked outside of give timeline?
- We are not thinking about the floor.
So, Final entities are:
- Reservation service
- Payment Service
- Load Balancer
- Postgres
- Redis
- Rate Limit Service
Detailed Component Design
Reservation Service: This service is going to take care of reserving, checkin, checkout for the users. It will communicate with Redis, Postgres, Payment gateway.
Postgres: For each spot there will be available time like 12:00 am - 12:30am, 12:30am - 1:00am, like this. We will store this in the database with the spot. As soon as blocked we will create new row stating that these slots are now booked for that spot in the Reservation table. We will also update the cache. Which is going to be write after cache. So it will happen in a single transaction.
Postgres Database will handle when two users are trying to reserve same spot at the same time using Atomicity and Isolation property. By locking the row. If race condition happens we can move onto the versioning the object.
Load Balancer: We will use Least connection algorithm of Nginx to distribute traffic across different nodes. So that it can handle traffic.
Redis: This will handle all available time for a given spot and date with a TTL of 10s. So that Instead of hitting database we can go to redis to answer immediately.
Rate Limit Service: Rate Limit service is responsible to drop request before it hits the request to the reservation service. so that attacks can be prevented.
Payment Service: Payment service is responsible to handoff the user to the payment by verifying the reservation and the amount. And handle after payment status.
Kafka: We will be using kafka to handle hot-lot surge problem. Where users will be placed in a queue until they receive a reservation complete event.