Loading...
Considering 4 entrance and each support 1 car at a time total 4 cars can enter at the same time.
100 Parking available at each floor and 5 floors are there in parking lot, so 500 cars can stay at a time. iLet's say each parking spot has max limit of 4 hrs so 6 times spot will be filled minimum. which makes it 3000 active users daily.
Let's say 360 customers shows up every hour. which make 60 every minute and 1 customer every second. so the QPS of system can be 1. or It should in single digits.
Since we are talking about supporting 500 parking spots, and this system should be centralized across multiple parking lots, We will capture each parking spot along with its lot id. we will maintained spot id, lot id, status (vacant, filled), starttime, endtime. Consider 4 byte columns, 20byes for one row and we maintain 500 rows for status for each spot. 1000bytes.
let's say system is supporting 1000 such parking lots. storage can 1MB for parking availability data. Now every hour we are expecting 360 customers so 1MB is for 1 hr. for 24 hrs it is 24 MB storage and consider 10 yrs operations along with history maintainance. 3650 days *24 MB =87600 MB ~ 100GB.
This should be database storage.
This is for data at rest, however to support smooth operation we would have streaming data flowing in from parking lot to server for availability status. which will need similar size pub sub system.
System needs
System will have a client portal, which will let customers view available spots and book them.
System will also have check-in and check-out supported from the same server. Here the client could be mobile app.
There is a Load balancer (LB) to handle the burst of traffic during peak hours.
User journey :-
Database will store the status about the parking spot availability. It can also have a ttl for booked spots in case of no show.
Database can clear the reservation if check-in didn't happen with in 1 hr after start time of reservation.
We can use SQL data base as there will be limited parking spots per parking lots.
We can have following data model/entities
We can also have further normalize the tables. Address table can be created further.
Reservation Service will update the spot_booking table with start_time, end_time and user_id, status,
We can also let user register with his information and payment preferences.
Checkin checkout service can be used simply to checkin and checkout from the parking lot, which also ensures that user's spot can be made available again for next booking. Status column in spot_booking table will support 3 Values BOOKED, IN, OUT. OUT is the default which means spot is available again.
Change log in this table will be replicated to long term storage for data analysis.
Data will be sharded location based. that means parking lots available in a zip code/city will be available in the same shard.
For analytics dataset as well, It can be partitioned based on location(zipcode) and parking lot level.
Reservation Service: This will offer set of APIs to complete parking spot reservation.
We are proposing Optimistic locking here for parking spots.
Retries: We propose a idempotency key in the request, to support retries during network failure. If something fails, client should retry using the same key and server will look up it's cache and status of booking and return the response.
If client makes a request with different idempotency key, it will be considered a new request.
Server will maintain a cache for storing idempotency key with a TTL of 10 mins.
Payment Retry:
Server will use the same idempotency key to avoid double charge. It will send the same key to payment gateway, and store an intermediate state called PAYMENT_PENDING, between HELD and BOOKED. when it retries with same idempotency key, payment gateway should not double charge and reservation server will update the status to BOOKED only after successful payment.