Loading...
The amount of people may vary on the each of the parking lots, but assuming we are taking care of all of the parking lots at once, assuming 100 parking lots with 30 spaces, and 5 different people in a slot per day, I would expect at least 100 * 30 * 5 = 45000 people per day at least, with request for parking + checking out (may need to see how), we are dealing with at least 100k requests per day per region. Assuming we are working with new parking / new members, about 100 bytes per new member and 10 bytes per parking, we are working with at least 100k * 10 + 100bytes * 45k = ~ 1.5million bytes -> 1,500,000 1.5Tb per day of transactions, so we would need to get some type of cloud storage.
Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...
POST /park {body contains User info + start time + expiration} - reserve Parking lot / check if parking is available / reserve the slot if not taken yet.
POST /pay {body contains User info + payment info if not in user} - process payment
PUT /park {parking_id + new time} - update time on the parking.
PUT /park/early/{park_id} - Early termination of the parking. Open up parking slot.
POST /gate/park_id - allows user to get out of the gate. The expiration time will be 30~1hour (depends on config) after the parking expire time.
PUT /park/no-show/{park_id} - Either leave it empty, or if user not checked in, open up parking slot. Refund depends on the config.
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.
I would choose SQL, since we aren't dealing with changing data models, our data is pretty strict.
Since we are dealing with a lot of reads and writes, I would work with PostgreSQL.
I would probably partition the database based on the location of each parking lots, like Database in LA would be different from database in SF, we would split the database based on the region.
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...
For the scaling, I would utilize event-driven scaling for each of the services. We would have a separate prometheus pod or other observability tool to get how many requests each pods are getting, and based on resource (cpu / memory utilization), or latency, we would scale up the # of the service containers, approximately around 70% utilization of resource.
When the user is reserving parking slots, we would need to make sure that the parking itself isn't taken already. In order ensure this, we would keep the parking_id / location_id / lot_id as a unique, when this parking is currently active. we would have some boolean on the parking to account for this. Of course, We would need to put a distributed lock on the parking lots themselves so that other reservation would not take it.
for the payment system, I would utilize 3rd party like stripe, the tradeoff here is less work for us/ technical overhead vs more cost.
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.