Loading...
[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
}
Out of Scope:
So, Final entities are:
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.