Loading...
List the key functional requirements for the system (Ask the AI for hints if stuck)...
Park request, pay, reservation, payment system
List the key non-functional requirements (performance, scalability, reliability, etc.)...
needs to scale with new parking lots adding this software
consistency over availabiblity, cant let reserve if its already full
Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...
hundreds of cars parked at a time per lot, but only a few entering. read write ratio pretty similar, maybe a little more read. smaller scale system compared to other softwares
Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...
GET/availability
POST/{user_id}/reserve
POST/{user_id}/park
GET/price
POST/{user_id}/pay
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.
user, load balancer (assign servers a certain number of parking lots each because theres only so busy each lot can be), rate limiter (can do very basic one because each lot cant receive that many calls at once, natural rate limiter at the gate), api gateway, cache (stores how busy each lot is, if certain lots are busier they'll be in the cache, add lots to cache when read request made on one not in cache, LFU cache type), database
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...
SQL db
many relational tables
lot info table, index by lot id:
lot_id, price/hour, capacity
car info table, index by car id,
car/user id, time entered lot, lot id, paid boolean
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.
reservation system:
user calls post/reserve with a time,
we call park with time entered lot in the future to accurately process pay. add new column that says reservation or just normal park
when they come actually park, we see they are already marked as in the parking lot, so we then update from reservation to normal park.
we also analyze the fact that two users may be trying to book at same time window if thres only 1 reservation left, need to make sure the later one gets a conflict error.